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"Our enemy is not terrorism, because terrorism is but a tactic. Our enemy is 
not terror, because terror is a state of mind, and as Americans we refuse to live 
in fear. Nor do we describe our enemy as jihadists or Islamists, because jihad 
is a holy struggle, a legitimate tenet of Islam." 


—-— Quote from Obongo's batshit—insane "counter-terrorism advisor" John 
Brennan. It's clear that if Barry isn't removed from office soon, we are all going to 
end up dead! 


This same Brennan kook also spread the myth that the Muslim terrorist detention 
facility in Guantanamo Bay, Cuba itself causes "terrorism," contradicting the above 
quote! 


The word "Guantanamo" is nowhere to be found in Usama bin Laden's original 1998 


fatwa. 
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INTRODUCTION 
1. GENERAL INFORMATION 
SCOPE 


1.01 This document provides information concerning 

the use of the Flexible Incoming Call 
Restriction (FICR) feature (formerly referred to 
as Slumber Service). 


REASON FOR REISSUE 


1.02 When this document is reissued, the reason 
for reissue will be stated in this paragraph. 


FEATURE AVAILABILITY 


1.03 The FICR feature is available in all active 

generic programs for No. 1 and No. 1A 
ESS. There is no unique base program dedicated 
to the FICR feature. It relies on existing base 
programs instead. 


2. DEFINITION/BACKGROUND 
DEFINITION 


2.01 The Flexible Incoming Call Restriction 
(FICR) feature is a line arrangement 
through which an individual customer station or a 
functional group of individual stations can be 
temporarily prohibited from receiving calls. 


BACKGROUND 


2.02 A station can be simultaneously affected by 

as many as three separate restrictions 
(individual plus group). Calls can still be originated 
on any restricted station provided that station is 
not under control of a restriction which prohibits 
call origination. An attendant can still reach a 
restricted station by using attendant emergency 
override. 


2.03 Termination restriction is accomplished with 

make-busy keys, and Call Forwarding-Busy 
Line (CFBL) provides termination treatment for 
the restricted calls. 


2.04 Call Forwarding-Variable (CFV) as 

well as disable ringer mechanisms, used in 
conjunction with Call Forwarding-Don’t Answer 
(CFDA) for termination treatment, can also be 
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used to provide both call restriction and termination 
treatment. However, these methods will not be 
described further in this document because operating 
procedures for the CFV restriction are the same 
as those for the existing CFV feature [see 
reference A(2) in Part 18] and because no standard 
implementation method exists for the disable ringer 
restriction. 


2.05 Individual stations which are to be restricted 

can often be placed in a nonhunt multiline 
group (MLG) arrangement in order to conserve 
translation memory. [See reference A(4) in Part 
18.] 


2.06 Several applications are available for FICR. 
One frequent application is in the control 
of hospital patient stations. In such an application, 
it is often desirable to prevent a single station from 
receiving calls (individual restriction) or to prevent 
an entire ward, floor, or hospital from receiving 
calls (group restriction). Other possible applications 
include hotels, college dormitories, or any other 
establishment where it is necessary to temporarily 
intercept incoming calls. Smaller applications include 
make-busy for switchboards, 50A CPS (customer 
premises system) consoles, and other stations. 


DESCRIPTION 
3. USER OPERATION 
CUSTOMER m 
A. Termination Restriction and Treatment 


3.01 Customer perspective for restriction via 
make-busy keys covers the following areas: 


(a) The restricted station 


(b 


a 


Special hardware on the customer’s premises 
(c) Activation and deactivation of the restriction 
(d) Termination treatment 
(e) The alternate destination. 

3.02 Any station can be associated with a make-busy 

key restriction. Calls can be made as usual 
on the restricted station, but no visual or audible 


indications are received when calls are placed to 
its number. 
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3.03 The association between this restriction 
method and its affected station(s) and the 

alternate destination can be changed only via 

arrangements with the telephone company. 


3.04 Each restriction requires a 2-position device 
for activation and deactivation. The device 
(hereafter called a key) can be an otherwise unused 
button on a keyset, call director, or console or a 
switch attached to a telephone or adjacent box. 


3.05 One of the key positions is the restriction 

active position. When a key is placed 
in this position, the associated station(s) is 
immediately restricted. The restriction remains 
active until the key is restored to the inactive 
position. At this time, any associated station 
can immediately receive calls, provided it is not 
under control of another active restriction. 


3.06 After the directory number (DN) of a 

restricted station is dialed, the calling party 
immediately receives audible ringing tone until the 
alternate destination answers. If the alternate 
destination cannot be reached, busy tone is received 
and continues until the calling party hangs up. 
The called restricted station receives no indication 
of the attempted call. 


3.07. The restricted call receives one of the 

following termination treatments. Generally, 
these treatments are fixed for a given restriction 
and can be changed only via arrangements with 
the telephone company. A treatment can be unique 
to a station, unique to a customer group, or 
occasionally shared by the restricted stations of 
several customers. 


(a) Call routed to a designated station 

or attendant: In this case, the designated 
station or attendant will usually be on the 
customer’s premises but can be located anywhere, 
even in another city. 


(b) Call routed to an announcement: 

The context of the announcement is not 
standard, but a statement such. as the following 
is recommended: “The party you have dialed 
is not to be disturbed at this time; if this is an 
emergency (or if you desire additional information), 
you may call nxx-xxxx for assistance.” 


(c) Call routed to an announcement with 
time-out to a designated station or 
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attendant: The restricted call is passed to a 
station or attendant if the caller does not 
disconnect after the announcement. In this case, 
a typical announcement would be: “The party 
you have dialed is not to be disturbed at this 
time. If this is an emergency (or if you desire 
additional information), do not hang up; an 
attendant will assist you shortly.” 


(d) Incoming call routed to a designated 

station or attendant and intra-business 
customer call to busy tone: This type of 
treatment is available only if the restricted station 
isin a group. The designated station or attendant 
may be located anywhere. 


(e) Incoming call routed to the business 

customer group attendant and 
intra-business customer call to an 
announcement: This type is also available 
only if the restricted station is in a business 
customer group. An incoming call is routed to 
the business customer group’s attendant. An 
intra-business customer call is routed to centrex 
common intercept. 


3.08 So that restricted calls can be properly 
answered at the alternate destination, limited 
call identification aids are available. One obvious 
means of identifying restricted calls at a station is 
to use dedicated lines which receive only restricted 
calls. However, restricted calls may be routed to 
an attendant console which receives several types 
of calls. In this case, visual call identification is 
available via certain call indicator lamps. 


3.09 If desired, the number of calls simultaneously 

directed to a single alternate destination 
can often be limited to a predetermined number. 
One use of this is to limit the load on the person(s) 
receiving the calls. Calls directed to a restricted 
station while the maximum number of simultaneous 
calls is in progress receive busy tone. 


3.10 If a 51A CPS attendant is used as an 

alternate destination, call indicator lamp 
indications may not be unique. The lamps used 
are the same ones that are used for the regular 
CFBL feature. 


B. Attendant Emergency Override 


3.11. A business customer station with an active 
make-busy key restriction and that is not 


off-hook can be reached by the attendant. The 
attendant accomplishes this by prefixing a special 
1- to 3-digit code to the extension number of the 
desired station. The attendant can also extend 
calls to the restricted station in this manner. The 
special code has the effect of overriding any active 
restrictions and prohibiting line hunting. All other 
aspects of the call remain the same as a normal 
(nonprefixed) call to the station. 


TELEPHONE COMPANY 


3.12 Not applicable. 


4. SYSTEM OPERATION 
HARDWARE 


4.01 Each make-busy key requires an SD-1A210 

(J1A033GA) remote master scanner applique 
circuit. A key device is needed on the customer’s 
premises, and a wire pair (or equivalent) is required 
to connect the key device to the applique at the 
central office. 


4.02 If used for the alternate destination, additional 

SD-1A218 (J1A032DC or J1A084DC) or 
SD-1A221 (J1A033DT or J1A088DT) announcement 
circuits may be required. If no alternate destination 
(CFBL DN) is provided, additional SD-1A218 busy 
tone circuits may be required. 


OFFICE DATA STRUCTURES 
A. Translations 


4.03 The translation layouts relevant to the FICR 
feature are summarized in Table A. See 

references A(2), A(4), and A(6) in Part 18 for 

detailed descriptions of the translation data. 


B. Parameters/Call Store 


4.04 There are no unique parameter words, 

associated set cards, or call store areas 
required for the FICR feature. However, any 
requirements of the features used to implement 
the FICR feature must be considered. 
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FEATURE OPERATION 
A. Termination Restriction and Treatment 


4.05 System implementation for restriction via 
make-busy keys covers the following areas: 


(a) Special hardware in the central office 
(b) Activation and deactivation of the restriction 


(c) Detection of an active restriction during a 
call 


(d) Termination treatment 
(e) The alternate destination 
(f) Attendant emergency override. 


4.06 Each make-busy key is connected to a wire 

pair (or equivalent) which is connected to 
the central office. Each wire pair from a key is 
connected to the master scanner via a remote master 
scanner applique circuit. 


4.07 The central office associates a given wire 

pair and its master scanner applique with a 
station or group of stations by using one of the 
following four features: Directed Scan Make-Busy 
(DSMB), Terminal Make-Busy (TMB), Random 
Make-Busy (RMB), or Group Make-Busy (GMB). 
4.08 Each master scanner point associated with 

a key using the TMB, RMB, or GMB schemes 
is so identified in the master scanner number (MSN) 
translation data. This data includes the associated 
MLG (TMB, RMB, and GMB are relevant only to 
lines in MLGs, including nonhunt) and for TMB, a 
list of the individual stations (terminals) affected 
by the key. With the RMB scheme, the stations 
affected by a key are identified in the MLG hunt 
list. With the DSMB and TMB schemes, each 
station affected by a key has the MSN stored in 
its LEN and DN translations. 


4.09 With all of these features, the position (active 

or inactive) of each key is detected at its 
associated MSN’s ferrod. The TMB, RMB, and 
GMB schemes require supervisory scan points; 
whereas, DSMB usually uses directed scan points. 
A supervisory scan detects each change in the 
position of a key for the TMB, RMB, and GMB 
schemes. For RMB, this causes an “RMB active” 
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TABLE A 


FICR FEATURE TRANSLATIONS 
TRANSLATION 
DATA AFFECTED 


LEN and/or DN auxiliary | Stores MSN in sleeve lead annex. 






METHOD OF RESTRICTION 
OR TERMINATION TREATMENT 


MAKE-BUSY KEY 


Directed Scan Make Busy 





































MLG hunt list. Sleeve lead indicator. 


LEN auxiliary block Stores MSN in sleeve lead annex. 
MLG hunt list. Sleeve lead indication. 







Terminal Make Busy 













UTYP 54 auxiliary block. | Stores base MSN for row of keys. 
MLG common block RMB feature indicator. 


MLG hunt list Indicates which RMB key affects 
each terminal. 


MSN auxiliary block. Stores associated MLG. 


MSN auxiliary block Stores MLG and list of affected 
terminals. 


Random Make Busy 







DN auxiliary block. Contains CFBL feature indicator 
and CFBL DN. 

Contains CFBL feature indicator 
and CFBL DN. 







« Group Make Busy 






Call Forwarding — Busy Line 














MLG common block. 







Options: 
Call Forwarding Unrestricted CFBL DN word. CFUS option indicator. 
Source 






CFBL DN word. CFILB option indicator. 


Centrex digit interpreter 
tables. 


Inhibit Forwarding If Line Busy 







ATTENDANT EMERGENCY OVERRIDE 












Contains subtype 18, sub-subtype 
11 final data for attendant 
override code. 






Attendant Access to Restricted 
Station 
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indication to be updated in the MLG headcell and 
the affected terminals’ MLG activity bits to be 
busied or idled. For GMB, a “GMB active” indicator 
in the MLG headcell is merely updated. For TMB, 
the MLG headcell is not altered, but the MLG 
activity bits of the affected stations are updated. 
The DSMB scheme does not use a supervisory scan, 
so no station memory is altered. Instead, a directed 
scan is made during each call. 


4.10 The technique used to detect a restricted 

station during a call depends upon the feature 
used to provide the station’s restriction. [See 
reference A(4) in Part 18.] These techniques are 
briefly described below: 


(a) Using DSMB: Every call placed to or 

which hunts to a station controlled by this 
feature performs a directed scan using the MSN 
stored in the station’s line translations. If the 
scan detects a busy condition, a scan point busy 
indicator (SPBI) is set in call store denoting that 
an active restriction was encountered during the 
call. At this point, any hunting in progress 
resumes; however, if the station is not part of 
a hunting arrangement or if the hunt is completed, 
the call proceeds to an all-stations-busy stage. 


(b) Using GMB: Every call placed to a station 

which is controlled by this feature examines 
the “GMB active” indicator in the MLG headcell 
to see if the GMB restriction is active. If so, 
the SPBI is set, and the call proceeds to the 
all-stations-busy stage. 


(c) Using TMB: When a call is placed to 

an individual station which is controlled by 
this feature but which is not part of a hunt 
MLG, the call proceeds as with DSMB. 
Unfortunately, when the TMB feature is used 
with stations which are part of a hunt MLG, 
detection of an active restriction is often not 
possible during a call. In particular, it is not 
possible if a station’s activity bit is busy; 
therefore, the SPBI cannot always be set properly. 
However, the line will appear busy, so no calls 
can terminate to it. 


(d) Using RMB: When a call is placed to 

an individual station which is not part of a 
hunt MLG, the “RMB active” indicator in the 
MLG headcell is examined. If it indicates the 
station is affected by an active RMB restriction, 
the SPBI is set and the call proceeds to the 
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all-stations-busy stage. When used with stations 
in a hunt MLG, this feature acts similarly to 
TMB. 


4.11 By using the provisions of the CFBL feature 
[see Table B and reference A(2) in 
Part 18), the types of termination treatment 
described in paragraph 3.07 can be given to calls 
which reach the all-stations-busy stage. A station 
which desires such termination treatment must 
have the CFBL feature; its associated CFBL DN 
is usually used to route a call to the alternate 
destination. Because the basic CFBL offering does 
not distinguish between a busy condition resulting 
from a make-busy key and one resulting from an 
off-hook line, the call forwarding inhibit line busy 
(CFILB) option can be used to insure that only 
calls which encounter active restrictions are 
forwarded. Calls which are not given such termination 
treatment are normally routed to busy tone. 


4.12 The following termination treatments apply 
to the make-busy key restriction: 


(a) Route calls to a designated station 

or attendant: If the designation is served 
by the same central office, the CFBL DN is 
the DN of the desired station or attendant. If 
served by another central office, the CFBL DN 
must be that of a remote call forward base 
station and the Remote Call Forwarding feature 
[see reference A(6) in Part 18] will route the 
call to the desired office. If the restricted station 
is in a business customer group, the call forwarding 
unrestricted source (CFUS) option must be used 
so that intra-business customer calls can also be 
forwarded to the destination via the CFBL DN. 


(b) Route calls to an announcement: 

The CFBL DN in this case is usually associated 
with a route index which points to the proper 
announcement trunk group. 


(c) Route calls to an announcement with 

time-out to a designated station or 
attendant: The delay announcement capability 
of the Queueing for Trunks and Lines (QTL) 
feature [see reference A(3) in Part 18] is used 
to provide the announcement. If the designated 
station or attendant is served by the same central 
office as the restricted station, it must have 
the delay announcement capability, and its DN 
must be the CFBL DN. If served by another 
central office, the CFBL DN can be that of a 
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TABLE B 


FICR FEATURE DOCUMENT REFERENCES 






Busy Verification of Lines 








Call Forwarding — Outside 
Call Forwarding — Variable 

Call Forwarding — Busy Line 

Call Forwarding — Don’t Answer 

Call Forwarding — Unrestricted Source 
Inhibit Forwarding If Line Busy 










Terminal Make Busy 
Random Make Busy 
Group Make Busy 


Remote Call Forwarding 


remote call forwarding base station whose remote 
station has the delay announcement capability. 
For business customer group stations, the call 
forward unrestricted source (CFUS) bit must be 
set to 1. 


(d) Route incoming calls to a designated 

station or attendant and intra-centrex 
calls to busy tone: To provide this type 
of treatment, the restricted station must be in 
a business customer group and have CFUS = 
0. If the designated station or attendant is 
served by the same central office, the CFBL DN 
is that of the desired station or attendant. 
Otherwise, the CFBL DN must be that of a 
remote call forward base station. When CFUS 
= 0, intra-business customer calls are routed to 
busy tone. 


(e) Route incoming calls to the business 

customer group attendant and 
intra-business customer calls to an 
announcement: The restricted station must 
be in a business customer group and have CFUS 
= 1. The CFBL DN must be that of an 


SECTION 
FEATURE USED FOR FICR NUMBER TITLE 





231-090-070 


231-090-073 


Queueing for Trunks and Lines 231-090-167 


231-090-180 


REMOTE CALL 
231-090-312 | FORWARDING 





BUSY VERIFICATION OF 
STATION LINES AND 
TIE TRUNKS 


























CALL FORWARDING 
FEATURES . 








QUEUEING FOR TRUNKS AND LINES 












HUNTING AND 
NO HUNTING FEATURE 






unassigned DN in the business customer group 
extension range. The business customer group 
must have the attendant intercept option. 

v 
If no alternate destination is provided for 
the restricted station (i.e, CFBL is not 
provided), restricted calls are routed to busy tone. 


4.13 


4.14 In most cases, restricted calls are routed to 
the alternate destination just as if they had 
been dialed directly. If the alternate destination 
is a station, including a 50A CPS console, restricted 
calls can be recognized at the destination only if 
dedicated lines are used. This is accomplished by 
using CFBL DNs, which are not listed in ‘any 
directory. If the final destination is a 51A CPS 
console, a restricted call will light one of three 
call indicator lamps on the display. These are the 
same lamps as are normally used with the CFBL 
feature. 


4.15 The alternate destination can have any 

features which are applicable to it under 
non-FICR applications. In particular, the Simulated 
Facilities feature [see reference A(5) in Part 18] 
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can be used on the CFBL DN to restrict the 
number of calls simultaneously directed to the 
alternate destination. The QTL feature may also 
be useful. 


B. Attendant Emergency Override 


4.16 To allow attendant access to a restricted 

station, a centrex special service code 
translates into a special sub-subtype (sub-subtype 11) 
of subtype 18 in the centrex digit interpreter tables. 
This allows the dialed extension, which is dialed 
after the special code, to be translated as if no 
restrictions were active. Specifically, make-busy 
conditions, active call forwards, and line hunting 
are ignored. The attendant terminates to dialed 
individual station if it is idle; otherwise, the 
attendant receives busy tone. 


CHARACTERISTICS 
5. FEATURE ASSIGNMENT 


5.01 The FICR feature is available on a per station 
or functional group basis. 


6. LIMITATIONS 
OPERATIONAL 

6.01 Not applicable. 
ASSIGNMENT 


6.02 Individual stations with common terminating 
features can be placed in nonhunt MLGs to 
achieve considerable translation memory savings. 
(See Part 14.) However, all their terminating data 
must be in common, particularly the CFBL DN. 
Certain equipment options, such as ground start 
and sleevelead, may differ as with hunt MLGs. 


6.03 The nonhunt MLG arrangement, as well as 

the hunt arrangement, allows a given station 
to be controlled by up to three restrictions. A 
station can have all the following methods of 
restriction: DSMB (or TMB) key, RMB key, and 
GMB key. 


6.04 The following associations are possible for 
restriction via make-busy keys: 


(a) A DSMB key can be associated with any 
individual station or a group of such stations. 
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(b) A TMB key can be associated with an 
individual station in an MLG or any group 
of such stations in the same MLG. 


“(c) A RMB key can be associated with an 
individual station in an MLG or any group 
of such stations in the same MLG. 


(d) A GMB key can be associated with any 
MLG. 


(e) A CFBL DN can be associated with an 

individual station not in an MLG or with an 
entire MLG. The “call forwarding unrestricted 
source” and CFILB options are associated with 
a station in the same manner. 


6.05 The attendant’s ability to reach a restricted 

station is an advantage over earlier forms 
of the FICR feature. Attendant override is 
accessible only by attendants and can be used to 
reach any restricted station in the business customer 
group. 


6.06 The FICR feature is generally not applicable 

to 2-party or multiparty lines because most 
of the features used to implement the FICR feature 
are not available for these lines. However, the 
DSMB and CFBL features are available for 2-party 
and multiparty lines, but the same scan point and 
CFBL DN must be used for each station on such 
aline. Thus, all stations are simultaneously affected 
by the make-busy key. 


6.07. The following limitations apply to the 
make-busy key method of restriction: 


(a) The number of DSMB and TMB keys or 

the number of stations controlled by such 
keys is limited only by the available scan points, 
applique mounting space, and memory or (for 
TMB) by the number of MLG stations. Any 
number of stations can be affected by the same 
DSMB key, and up to 20 stations can be affected 
by the same TMB key. Each individual station 
can be associated with only one such key and 
cannot be controlled by both a DSMB and a 
TMB key. 


(b) The number of RMB keys or the number 

of stations controlled by such keys is limited 
by either the available master scanner points, 
applique mounting space, and memory or by 
the number of MLGs. Each MLG station can 
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be affected by only one such key, but any 
number of stations in the same MLG can be 
controlled by the same key. A single MLG can 
have up to 10 RMB keys. 


(c) A MLG can have only one GMB key affecting 

all stations within the group. As with 
RMB keys, the limiting factor is either available 
scan points, applique mounting space, and 
memory or the number of MLGs. 


(d) An individual station can be associated with 
only one CFBL DN. 


7. INTERACTIONS 
STATIC 


7.01 Not applicable. 


DYNAMIC 


7.02 All normal interactions of the features used 

to implement the FICR feature also apply 
in FICR applications. These features and the 
respective feature document references are listed 
in Table B. 


7.03 When the make-busy key method is used, 

line hunting takes precedence over the CFBL 
termination treatment. When a restricted individual 
station is encountered, line hunting continues. The 
alternate destination is reached only if the hunt 
fails. 


If an individual station in a hunt MLG is 
controlled by a TMB or RMB key, an active 
restriction cannot always be detected during a line 
hunt. However, the line always appears busy, so 
calls will not terminate to it. The net result is 
that the CFILB option often has no effect, with 
some calls routing to the alernate destination and 
others routing to busy tone. 


7.04 


7.05 Ifa hunt MLG station is controlled by several 
make-busy restrictions, the system detects 
the restrictions in the following order: GMB, 
RMB, and TMB or DSMB. For all other stations, 
the order in which applicable restrictions take place 
is GMB, TMB or DSMB, and RMB. No station 
can have both the TMB and DSMB features. If a 
station also has CFV active, CFV takes precedence 
over all make-busy restrictions. 
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7.06 A station with a make-busy key restriction 

and using the CFBL feature for termination 
treatment can also have the regular CFBL feature 
(CFILB = 0). However, the alternate destination 
then receives both busy-line forwarded calls and 
make-busy forwarded calls because the same 
CFBL DN is used in both cases. 


7.07. When a restriction is activated against an 
individual station, existing active restrictions 
affecting the station remain effective. Likewise, 
when a restriction is deactivated, all other active 
restrictions against the station remain effective. 


If a station has an active restriction and its 
alternate destination is also under an active 
restriction with an alternate destination, then 
multiple-call forwarding can take place. 


7.08 


8. RESTRICTION CAPABILITY 


8.01 Not applicable. 


INCORPORATION INTO SYSTEM 
9. INSTALLATION/ ADDITION /DELETION 
9.01 Refer to Fig. 1 for an illustration showing 


the implementation procedure for the FICR 
feature. Refer to Part 13 for testing. 


10. HARDWARE REQUIREMENTS 

Note: This part contains cost factors and 
determination of quantities. Central Office 
Equipment Engineering System (COESS) 
Planning and Mechanized Ordering Modules 
are the recommended procedures for developing 
these requirements. However, for planning 
purposes or if COEES is not available, the 
following guidelines may be used. 


It is recommended that entire master 
scanner rows be dedicated to RMB and 
GMB keys or to TMB keys rather than mix them 
with other types of MSN assignments. This conserves 
both program store memory and system real time. 


10.01 


10.02 The SD-1A210-01 remote master scanner 

applique circuit (order codes 10470, 10471, 
10472, or 10478) is wired eight circuits per unit 
on a miscellaneous trunk frame. One circuit is 
required for each key restriction and is connected 
via a wire pair (or equivalent). In lieu of a physical 
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wire pair connecting each of a customer’s keys to 
an applique circuit, a carrier facility can be used. 
One method uses standard off-the-shelf items (405A, 
B data set and 1C431 interface) to send from 8 to 
32 key indications over a single wire pair. Other 
methods using commercial items can be devised on 
a local basis. 


10.03 Announcement circuits SD-1A218-01 (order 

code 07870) and SD-1A221-01 (order codes 
07970, 07971, 07972, 07904, 07905 or 07906) or 
miniaturized circuits SD-1A218-05 (order code 07800) 
and SD-1A221-05 (order codes 07901 or 07903) used 
for termination treatment are engineered in the 
standard manner. [See reference A(17) in Part 18.] 
The use of ESS announcement channels may not 
always be economical because the nature of the 
announcement may require that one or more 
channels be dedicated per customer. Recorded 
announcement devices located on customer premises 
and connected to the central office via lines should 
be considered in such cases. 


10.04 The use of busy tone for treatment when 

an alternate destination is not provided has 
the effect of increasing the number of terminating 
calls which encounter busy. For most applications, 
this effect is negligible. However, it may have to 
be considered when engineering busy tone circuits 
SD-1A218-01 for new offices and large FICR 
additions. 


10.05 For determination of quantities of service 
circuits, see reference A(17) in Part 18. 


11. SOFTWARE REQUIREMENTS 


Note: This part contains cost factors and 
determination of quantities. Central Office 
Equipment Engineering System (COEES) 
Planning and Mechanized Ordering Modules 
are the recommended procedures for developing 
these requirements. However, for planning 
purposes or if COEES is not available, the 
following guidelines may be used. 


GENERAL 


11.01 For several of the cost data areas covered 

here, it will only be necessary to provide 
approximations. This is particularly true when 
specifying PS and CS memory and system cycle 
time costs. Frequently, the possible data combinations 
and program sequences are too complex for exact 
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numbers to be provided. However, these 
approximations should be adequate. 


11.02 The following cost data for controlled 

stations assumes that all other characteristics 
of the station have been taken into account. For 
example, if a DSMB key requires two additional 
words per LEN, this assumes the LEN already 
requires an auxiliary block. If the LEN were 
abbreviated, the PS word cost of going to an 
auxiliary block must be added to the two words. 
Similarly, the PS word cost of rearranging individual 
non-MLG stations into a nonhunt MLG must be 
taken into account. Usually, this amounts to about 
1 additional PS word per station, plus 20 PS words 
and 4 + N/16 CS words per MLG. 


11.03 Other general cost items not covered in 

the following breakdown include those for 
the alternate destination—dedicated lines and DNs 
and the associated memory, announcement channels 
and trunks, and their associated memory. In 
addition, the basic overhead (nonstation related 
costs) of providing features such as CFBL must 
be taken into account. 


MEMORY 

A. NO. 1 ESS 

Fixed 

11.04 None. ’ 

Conditional 

11.05 None. 

Variable 

11.06 The following memory is required when 
the feature is added on a per individual 

line or MLG basis using the make-busy key feature: 

e Translation (program store): 
(1) With DSMB feature: Four program 
store words for each non-MLG individual 

station or two words for each MLG individual 
station for storing the MSN in the LEN 


and/or DN translations. 


(2) With TMB feature: Four program 
store words for each non-MLG individual 
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station or two words for each MLG individual 
station for storing the MSN in the LEN 
and/or DN translations. To identify the 
restricted stations in the MSN translations, 
2 + N/2 program store words (where N 
is the number of stations associated with 
the TMB key) are required. 


(3) With RMB feature: Two program store 
words per key for storing MSN data 
‘in the MSN translator. 


(4) With GMB feature: Two program store 
words per key for storing MSN data 
in the MSN translator. 


(5) Termination treatment for above 

methods: One program store word per 
non-MLG station or one program store word 
per MLG is required for storing the 
CFBL DN when the CFBL feature is used. 
If no alternate destination (i.e., no CFBL) 
is provided, additional memory is required 
if additional busy tone circuits are needed. 


B. NO. 1A ESS 
Fixed 

11.07. None. 
Conditional 
11.08 None. 
Variable 


11.09 The following memory is required when 
the feature is added on a per individual 
line or MLG basis using the make-busy key feature: 


e Translation (unduplicated call store, 
file store): 


(1) With DSMB feature: Four words for 

each non-MLG individual station or 
two words for each MLG individual station 
for storing the MSN in the LEN and/or 
DN translations. 


(2) With TMB feature: Four words for 

each non-MLG individual station or 
two words for each MLG individual station 
for storing the MSN in the LEN and/or 
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DN translations. To identify the restricted 
stations in the MSN translations, 2 + N/2 
words (where N is the number of stations 
associated with the TMB key) are required. 


(3) With RMB feature: Two words per 
key for storing MSN data in the 
MSN translator. 


(4) With GMB feature: Two words per 
key for storing MSN data in the 
MSN translator. 


(5) Termination treatment for above 

methods: One word per non-MLG station 
or one word per MLG is required for storing 
the CFBL DN when the CFBL feature is 
used. If no alternate destination (i.e., no 
CFBL) is provided, additional memory is 
required if additional busy tone circuits are 
needed. 


REAL TIME IMPACT 
A. No. 1 ESS 


11.10 The real-time costs for the make-busy key 
method of restriction are as follows. These 
costs are above those incurred on calls to and from 
unrestricted stations or stations which do not have 
FICR. 
(1) For DSMB: 100 cycles per call placed to 
or from an associated non-MLG station or 
150 cycles per call placed to or from an associated 
MLG station. (Note that 150 or more cycles are 
consumed for each associated individual MLG station 
examined during a hunt. Therefore, the 
DSMB method should be used cautiously with 
hunt MLGs.) 


(2) For TMB: 100 cycles per call placed to or 
from an associated MLG station. In addition, 
100 + (10 * N) cycles per activation or deactivation 
where N is the number of individual stations 
controlled by the key, are consumed. 


(3) For RMB: 10 cycles per call placed to an 

associated nonhunt MLG station. In addition, 
50 cycles per activation and 100 + (20 * N) 
cycles per deactivation, where N is the number 
of individual stations controlled by the key, are 
consumed. 
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(4) For GMB: 50 cycles per activation or 
deactivation of restriction. 


(5) For termination treatment: 100 cycles if a 
CFBL DN is used. 


11.11 The cycle time in No. 1 ESS is 5.5 usec. 
B. No. 1A ESS 


11.12. The real-time costs for the make-busy key 

method of restriction are as follows. These 
costs are above those incurred on calls to and from 
unrestricted stations or stations which do not have 
FICR. 


(1) For DSMB: 200 cycles per call placed to 

or from an associated non-MLG station or 
300 cycles per call placed to or from an associated 
MLG station. (Note that 300 or more cycles are 
consumed for each associated individual MLG station 
examined during the hunt. Therefore, the DSMB 
method should be used cautiously with hunt 
MLGs.) 


(2) For TMB: 200 cycles per call placed to or 

from an associated MLG station. In addition, 
200 + (20 * N) cycles per activation or deactivation, 
where N is the number of individual stations 
controlled by the key, are consumed. 


(3) For RMB: 20 cycles per call placed to an 

associated nonhunt MLG station. In addition, 
100 cycles per activation and 200 + (40 * N) 
cycles per deactivation, where N is the number 
of individual stations controlled by the key, are 
consumed. 


(4) For GMB: 100 cycles per activation or 
deactivation of restriction. 


(5) For termination treatment: 200 cycles if a 
CFBL DN is used. 


11.13 The cycle time in No. 1A ESS is 
0.7 usec. 


12. DATA ASSIGNMENTS AND RECORDS 
TRANSLATION FORMS 
12.01 There are no new ESS translation forms 


or form entries for the FICR feature. 
Standard form entries on the following ESS forms 
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are required to implement the FICR feature. [See 
reference C(1) in Part 18.] 


(a) ESS 1101—Directory Number Record—is 

used to identify the DNs belonging to the 
customer’s MLG or centrex group. This form 
contains the CFILB option indicator. 


(b) ESS 1107—Supplementary Information 
Record—is used to record CFBL, CFUS, 
TMB, and DSMB (MSN) options. 


(c) ESS 1109—Centex Group Record—provides 

records of the business customer features 
and access codes. The attendant emergency 
override entry (sub-subtype 11) is made on this 
form. 


(d) ESS 1115—Multiline Group Record—is used 

to maintain records of both hunt and nonhunt 
MLGs in CTX-8 and later generic programs. 
CFILB, RMB, and GMB entries are made on 
this form. 


RECENT CHANGES 


12.02 There are no new or unique recent change 

(RC) message formats uSed to implement 
the FICR feature. Details concerning the following 
RC formats used to implement the FICR feature 
can be found in the associated references. 


RC MESSAGES 


RC:LINE [References A(9) or A(11) in Part 18] 
RC:MLHG [References A(9) or A(11) in Part 18] 
RC:MSN [References A(7) or A(12) in Part 18] 
RC:CTXCB [References A(8) or A(18) in Part 18] 
RC:CTXDI [References A(8) or A(13) in Part 18}. 


13. TESTING 


13.01 Testing consists of ensuring that calls 

originating from and terminating to the 
restricted station(s) are processed properly. 
Numerous combinations of active and inactive 
restrictions should be tried. These tests are 
normally performed after customer cutover. Limited 
terminating call tests can be performed prior to 
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office cutover by using cutover access lines to call 
customer stations. 


13.02 The customer’s translation data should be 
verified by using the following teletypewriter 
input messages: 


(a) Use the VFY-LEN input message to verify 

the line equipment number translations for 
the customer station(s). The system response 
to this message is a TRO3 output message. 


(b) Use the VFY-DN input message to verify 

the directory number translations for the 
customer’s station(s). The system response to 
this message is a TRO1 output message. 


(c) Use the VFY-CSTG-34 input message to 

verify the common block entries for the 
customer’s MLG. The system response to this 
message is a TR15 output message. 


(d) Use the VFY-CSTG-85 input message to 

verify the common block entries for the 
customer’s centrex group. The system response 
to this message is a TR17 output message. 


(e) Use the VFY-CTSG-36 input message to 

verify the hunting list of the customer’s 
MLG. The system response to this message is 
a TR16 output message. 


(f) Use the VFY-XDGNT input message to 

verify that the customer’s centrex digit 
interpreter tables contain sub-subtype 11 final 
data for the attendant override code. The system 
response to this message is a TR18 output 
message. 


(g) Use the VFY-MSN input message to verify 

the master scanner number translation(s) 
for customers using the make-busy key control 
method of slumber service. The system response 
to this message is a TR12 output message. 


14. OTHER PLANNING TOPICS 


14.01 Certain methods of restriction and termination 

treatment may be more economical or 
feasible than others for a given application. There 
are no hard and fast rules for determining the 
best method; however, some guidelines are given 
in paragraphs 14.02 through 14.06. 
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14.02 If a station is not in a hunt MLG and 

cannot be part of a nonhunt MLG (does 
not have terminating data in common with other 
stations), the DSMB (or even the disable ringer or 
CFV methods) must be used for restriction. 


14.03 A nonhunt MLG should be formed when 
15 or more of a customer’s stations satisfy 
the requirements of a nonhunt MLG. A hunt 
MLG should be formed when there are eight or 
more stations in a hunt sequence. If it is essential 
that a station have more than one make-busy 
restriction, it must be placed in an MLG. 


14.04 If a MLG is to be used, the following 
guidelines apply: 


(a) GMB should be used for a group restriction 

when an entire MLG is to be affected by 
the same restriction and is to use the same 
alternate destination. 


(b) RMB should be used for a group restriction 

when five or more (but less than all) stations 
are to be affected by the same restriction and 
are to use the same alternate destination. In 
general, RMB should be used for a customer’s 
larger group restrictions. 


(c) TMB should be used with a hunt MLG for 

individual restrictions, for group restrictions 
when RMB key8 are exhausted, and when the 
same alternate destination is to be used. 


(d) DSMB should be used with a nonhunt MLG 

for individual restrictions, for group restrictions 
when RMB keys are exhausted, and when the 
same alternate destination is to be used. 


14.05 Use of the make-busy key method without 

the CFBL feature should be avoided. 
Providing alternate destinations that provide useful 
information to the caller will increase the completion 
rate and decrease the retry rate. 


14.06 <A DN used to route calls to the alternate 

destination can be called directly, subject 
only to normal screening. To reduce the likelihood 
of people calling these destinations, unlisted DNs 
should be used when desirable. 
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ADMINISTRATION 
15. MEASUREMENTS 
15.01 There are no new traffic or plant measurements 
for the FICR feature. However, the 
standard traffic measurements for MLGs, business 
customer groups, and CFBL can be useful. See 
reference A(16) in Part 18 for more information 
on type measurement codes. 
15.02 The traffic line group measurement can be 
used to count the number of calls to a 
make-busy restricted DN. This should only be 
used for temporary studies since it requires additional 
program store and call store memory. 
16. CHARGING 
AUTOMATIC MESSAGE ACCOUNTING 
16.01 Not applicable. 
UNIFORM SERVICE ORDER CODES 


16.02 The uniform service order codes for the 
FICR feature are listed below: 


(a) FRD—Attendant position intercept, initial 
intercept line per FICR group 


(b) FRE—Control key 


(c) FRG—Common equipment, per group of 
stations 


(d) FRA—Each station line equipped. 
SUPPLEMENTARY INFORMATION 
17. GLOSSARY 
17.01 Not applicable. 
18. REFERENCES 
18.01 The following documentation contains 
information pertaining to or affected by 
FICR. 
A. Bell System Practices 
(1) Section 231-090-070—Feature Document— 
Busy-Verification of Station Lines (BVL) 
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and Centrex Trunks (BVT) Features—2-Wire 
No. 1 and No. 1A Electronic Switching Systems 


(2) Section 231-090-073—Feature Document—Call 
Forwarding Features—2-Wire No. 1 and 
No. 1A Electronic Switching Systems 


(3) Section 231-090-167—Feature Document— 
Queueing for Trunks and Lines—2-Wire 
No. 1 and No. 1A Electronic Switching Systems 


(4) Section 231-090-180—Feature Document— 

Multiline Groups—Hunting and No Hunting 
Feature—2-Wire No. 1 and No. 1A Electronic 
Switching Systems 


(5) Section 231-090-229—Feature Document— 
Simulated Facilities Feature—2-Wire No. 1 
and No. 1A Electronic Switching Systems 


(6) Section 231-090-312—Feature Document— 
Remote Call Forwarding (RCF) Feature—2-Wire 
No. 1 and No. 1A Electronic Switching Systems 


(7) Section 231-118-325—RC Procedures for 

PSWD, GENT, PSBLK, and SUBTRAN 
(CTX-6 Through 1E5 Generic Programs)—2-Wire 
No. 1 Electronic Switching System 


(8) Section 231-118-331—Centrex-CO Recent 

Change Procedures for CTXCB, CTXDI, 
CTXEXR, CXDICH, DITABS, DLG, FLXDG, 
FLXRD, and FLXRS (CTX-6 Through 1E5 Generic 
Programs)—2-Wire No. 1 Electronic Switching 
System 


(9) Section 231-118-335—Line Recent Change 

Procedures for LINE, TWOPTY, MPTY, 
SCLIST, MLGH, ACT, and CFV (CTX-7 through 
1E5 Generic Programs)—2-Wire No. 1 Electronic 
Switching System 


(10) Section 231-118-337—RC Procedures for 

ANIDL, CAMA, CFG, CPD, MSN, NMTGC, 
PLM, ROTL, SIMFAC, and TMBCGA (CTX-6 
Through 1E5 Generic Programs)—2-Wire No. 1 
Electronic Switching System 


(11) Section 231-318-302—Line Recent Change 

Procedures for LINE, TWOPTY, MPTY, 
SCLIST, MLHG, CFV and OBS (Through 1AE5 
Generic Programs)—2-Wire No. 1A Electronic 
Switching System 
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(12) Section 2381-318-305—RC Procedures for 

PSWD, PSBLK, SUBTRAN, and GENT 
(Through 1AE5 Generic Programs)—2-Wire No. 
1A Electronic Switching System 


(13) Section 231-318-309—Centrex-CO Recent 

Change Procedures for CTXCB, CTXDI, 
CTXEXR, CXDICH, DITABS, DLG, FLXDG, 
FLXRD, and FLXRS (Through 1AE5 Generic 
Programs)—2-Wire No. 1A Electronic Switching 
System 


(14) Section 231-318-310—RC Procedures for 

ANIDL, CAMA, CFG, CPD, JUNCT, MSN, 
NMTGC, PLM, ROTL, SIMFAC, TMBCGA, and 
CLAM (Through 1AE5 Generic Programs)—2-Wire 
No. 1A Electronic Switching System 


(15) Section 966-102-100—Centrex and PBX-CO 
Service General Description—2-Wire No. 1 
Electronic Switching System 


(16) Section 231-120-301—Traffic Measurements— 
2-Wire No. 1 Electronic Switching System 


(17) Section 231-060-210—Service Circuits—2-Wire 
No. 1 and No. 1A Electronic Switching 
Systems 


(18) Section 231-061-450—Program Store—2-Wire 
No. 1 Electronic Switching System 


(19) Section 231-062-470—Processor Community 
Engineering—UnduplicatedCallStores—2-Wire 
No. 1A Electronic Switching System 
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(20) Section 231-062-475—Processor Community 
Engineering—File Stores—2-Wire No. 1A 
Electronic Switching System. 


TTY Input and Output Manuals 


(1) Input Message Manual IM-1A001, No. 1 
Electronic Switching System 


(2) Input Message Manual IM-6A001, No. 1A 
Electronic Switching System 


(3) Output Message Manual OM-1A001, No. 1 
Electronic Switching System 


(4) Output Message Manual OM-6A001, No. 1A 
Electronic Switching System. 


Other Documentation 


(1) Translation Guide TG-1A, 2-Wire No. 1 and 
No. 1A Electronic Switching Systems 


(2) Translation Output Configuration PA-591008, 
No. 1 Electronic Switching System 


(3) Translation Output Configuration PA-6A002, 
No. 1A Electronic Switching System 


(4) GL 74-02-078 (EL 3098)—Development of 
Types of Hunting Arrangements and Make-Busy 
Keys for Multiline Hunt Groups. 
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3.1.14 GDS-SOP Interface 
A. Introduction 


The GDS-SOP interface provides the link by which both corrected and noncorrected POTS installation 
orders may be completed or returned on the GDS completion screen and the completion information 
automatically sent back to the Service Order Processor (SOP). Corrected orders are defined as orders 
that require changes to the body of the service order (i.e, S&E, BILL). Noncorrected orders are those 
orders, both field-visit and nonfield-visit, that do not have changes to the body of the service order (i.e., 
S&E). Information between the two systems is transmitted via TCM. Autocomplete supplements the 
former completion process, requiring the manual input of a completion message retrieved from a printer 
into the SOP. 


B. Required Table Entries 
To utilize this feature the following must be available: 


1. Appropriate entries must be made in the following TTS tables: 


a. GDS OPTIONS - The ACMP-ON field will be populated with an entry of "Y" indicating 
that order completion information from this center should flow to the SOP. ACMP-ON is 
controlled by the Feature Authorization Module (FAM), which was described earlier in 
Section 3. An entry in an optional field, ACMPPATH, will divide messages (in TCM) to the 
SOP by GDS center. This field would be useful if all messages from one center (and only 
that center) needed to be held. 


b. GDS SOP EDITS - This table will be built with the SOP as the Table Key and the FID# 
(01-30) as the Table Record Key. Through the information built into this table, the user- 
defined field names found in the Order Stat section of the completion screen can have 
certain characteristics assigned to them. These edit rules must be followed to result in a 
successful completion message flow to the SOP. This table also contains default values for 
non-field visit orders. 

¢. GDS SOP OPTIONS - This table defines interface options for each SOP. Entries in this 
table are used to determine the TCM SEC (System Entity Codt) for a SOP. The 
determination to send or not to send PAC orders to a SOP is also made in this table. 
Options for the autocompletion of corrected orders are also defined in this table. 


d. GDS SOI PARSE - This table will be built using the SOP as the Table Key and the parse 
option "AC" (AutoComplete) as the Table Record Key. The center should be blank. GDS 
SOI PARSE is used to determine which sections of the service order may be viewed on 
GDCMP?2 during the completion process. 


2. Entries in the GDSOP (GDS Service Order Processors) table will determine to which SOP 
completion information for a wire center and CSC should be sent. The "DELMIN" and "DELOFF" 
entries determine, respectively, the length of time a message should be held in TCM before being 
passed to the SOP if the order is delayed and the time of day at which completion information 
should be sent immediately, regardless of the DELMIN entry. 


C. Completion Process 


Several fields relating to the autocompletion process on the GDCOMP screen will need the appropriate 
entry to allow the autocompletion to occur. 


PROPRIETARY — BELLCORE AND AUTHORIZED CLIENTS ONLY 
See proprietary restrictions on title page. 
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1. The SOP flag determines whether a message will automatically be sent to the SOP. An entry of 
"Y" is required for the autocompletion process. If "N,” nothing will be passed to the SOP; the 
completion message will be sent for manual completion. This flag defaults to the value of ACMP- 
ON in the GDS OPTIONS table. SOP will be "N" for manually added orders, orders that have 
been uncompleted, multi-term orders, and orders with NOTIFY set to no. If SOP is "Y," it can be 
updated to "N"; however, system generated values of "N" cannot be updated to "Y." 


2. The PR flag determines whether the completion message will be printed. If PR is “Y," the 
completion message will be printed at the printer designated in the GDS SOC PRINTER or GDS 
OPTIONS table so that the order can be completed manually. This flag defaults to the opposite 
of the SOP flag. If the SOP flag is updated, however, the PR flag must also be updated (i.., if 
SOP is updated to "N,” PR must be updated to "Y" if a printed completion message is wanted for 
a manual completion). 


3. The SOI flag determines whether the service order image will be printed with the completion 
message. If SOT is "Y", the service order image will be printed with the completion message. SOT 
defaults to "N." 


4. The DELAY field entry is dependent upon the user’s desire to have completion messages held in 
the TCM before passage to the SOP, and applies to an order only if the user indicates that it 
should. A "Y" entry will then take the "DELMIN” value previously established in the GDSOP 
table as its hold period. If an "N" is entered in the DELAY field, the completion message will be 
transmitted immediately. The default for this flag is "N". 


5. AY" entry in the EDIT field will invoke the edit process (as established in the TTS table, GDS 
SOP EDITS) when the "COMPLETE" or RETURN command is executed. Edit errors will block 
completion and the field(s) in error will be highlighted. This flag defaults to "Y", and can only be 
changed to "N" if SOP is "N". 


6. The POP (autopopulate) field is not currently being utilized. 


7. A maximum of ten CHANGES flags will be displayed on the screen, one for each section defined in 
the GDS SOI PARSE table in the "AC" entry. If there are corrections to the service order, the 
sections requiring changes must be marked with a "Y." If any of the marked sections is listed in 
the DELAY field of the GDS SOP OPTIONS table, the message will be delayed by the number of 
minutes specified in the DEL MIN field in the GDSOP table. If SOP is "Y" and any of the marked 
sections are listed in the PG2 field in GDS SOP OPTIONS, corrections to the service order will be 
entered on GDCMP2. 


After entering the required information on the GDCOMP screen and executing the “COMPLETE” 
command, the completion process begins. If all the user-defined edit rules are met, noncorrected orders 
will be completed at this point and ORDER STATs will be passed back to the SOP. If a corrected 
order is being processed, however, GDCMP2 will now be displayed providing the appropriate flags were 
set. Corrections must. be entered for all selected sections which are also defined in PG2. After all of the 
required correction information is entered, the order will be completed and the order statistics and 
correction information will be passed to the SOP. 


If a job was RETurned in GDS, it will not be completed in the SOP, but ORDER STAT information 
may be passed to the SOP. Edit rules will be invoked for those ORDER STAT fields that are to be 
passed to the SOP on a RETurn, and for any other fields that are populated. These rules must be 
passed before the job will be RETurned. Corrections may not be entered at the time of a RETurn. 
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Since an order with multiple TERMS is viewed as multiple jobs in GDS, it will not be autocompleted in 
the SOP. When all TERMS are complete, a completion message consisting of the JOBID and ORDER 
STATS for all the jobs will be sent to a printer. The completion message will be produced when either 
the last TERM is completed or the last open TERM is cancelled. The order must then be completed 
manually in the SOP. 


D. Completion Information from GDS 


When a job is completed or returned, GDS will pass to SOP the following information: 


JOBID (order number) 

Completion Date/Time (in GDS) 

TN/CKTID 

#CKTS (number of non-cancelled lines) 

Handling Code 

CMP/RET indicator 

SOP Code 

Correction Flags (indicate what, if anything, is corrected) 
Security Code 

ORDER STATS field names 

ORDER STATS field values 

CORRECTED flag 

The first ninety characters of the COMMENTS field 
Appropriate correction information. 


The information that is passed to the SOP will be in FCIF (Flexible Computer Interface Format). The 
SOP will then have to process this information to complete the order. 


E. Messages 


b. 


3-44 


An Autocompletion message is sent by GDS to SOP via TCM when the user executes a successful 
"COMP" command. This will be a message class of 3 with a scenario type of A (TCM to non- 
TCM). 4 


SOP will send an acknowledgment message to TCM. Every Class 1 or Class 3 message passing 
through TCM must be acknowledged and the acknowledgment can be either positive, negative, or 
warning. The acknowledgment here should always be positive if SOP will provide another message 
back to GDS (see 3). 


For companies wishing to maintain completion status information in GDS, an optional response 
message is sent from SOP to GDS via TCM. This message is sent at the same time or shortly 
after the acknowledgment message to TCM. The message contains the SOP’s completion date and 
time, order status, and some descriptive text. This message will be a class 1 and scenario type of 
Z, which is non-TCM to TCM. 


A TCM Acknowledgment message is generated by GDS when the SOP response message is 
received. The message sent will be class 2 with a scenario type of A. A negative acknowledgment 
will be produced by GDS if the SOP response message is missing key data or a database error is 
encountered. The SOP can choose whether or not to receive this acknowledgment based upon its 
population of control fields (EPATHID and PPATHID) in its response message. 
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Once all required data is present and valid, GDS will receive and store a status code and up to forty 
characters of information from the SOP. This information will be stored as an IIN event in the Log 
History database. Both the status code and the accompanying information will be accessible via TQS 
(TIRKS Query System). This message will include the following fields: 


Order Number (GDS JOBID) 
SOP code 

Completion Date/Time (in SOP) 
SOP status 

Message text 


The SOP status code is a one character code and indicates what actions are to be taken with regard to 
the order by GDS and the status of the order in the SOP. The following values are valid: 


SOP Status 


Qn © NS 


SOP Action GDS Action 
Order Completed Nothing 
Order Open Nothing 
Order Open Print Exception Notice 
Order Open Resend Completion Message 
Order Open Print Exception and Resend 
Order Rejected Print Exception 
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8.1.15 Data Matching in GDS (GDS Designed Data Interface) 


This section describes the GDS designed data interface receiver matching algorithm. One of the 
primary functions of the designed data interface receiver module in GDS is to match the service order 
data to the design data by using a matching algorithm. GDS builds a work request from job data 
received off the Service Order Image from either SOAC or the SOP. The Work Request data includes 
order level information (customer name, billing telephone number, due date, etc.), CKL information 
(address, USOCS, etc.), and item information (circuit ID, facilities, etc.). GDS also receives design data 
(circuit end, critical dates, CLO, etc.) for special service circuits from CIMAP/DOC, 

The work request database contains a work request record consisting of an order segment, multiple CKL 
segments, and multiple item segments. Each CKL segment is a separate work location identified by a 
CKL address and CKLID. Each item segment is identified by a circuit ID. The matching algorithm 
utilizes data in each segment type to identify the correct order-CKL-item segments to match with. The 
data that is involved in the matching algorithm is illustrated in the following table: 


fenter [onder [5 derived “Yo aed 
[eireuit end | CKL | ST LOOPR loop 


The matching algorithm makes two separate attempts to identify the correct work request using the 
circuit ID and JOBID indices. The match process continues until a rule is met which then terminates 
match processing. If no match rule is met, the GDS center is identified by routing and the work request 
is added to the Work Request database. If a work request already exists, a new CKL/item is added to 
the existing order segment. 









A match rule identifier has been placed in the IIN event for receipt of the data in GDLOG. The 
identifier consists of two characters that identify the fields used in the match process. 


The match rules are presented in priority order. The name of each match rule is enclosed in 
parentheses. 
1. JOB, CKLID and circuit ID (W1) 


Using the entire circuit ID, the index is used to identify a possible item segment for match. If the 
JOBIDs are equal (order segment) and CKLIDs are equal (CK segment), it is considered a match. 
The CKL action must be add or reuse for this rule. If the rule is met, the order, CKL, and item 
segments are updated with the design data. 


2. JOBID, disconnect CKL action and circuit ID (W2) 


Since the CKLID is not provided for the disconnect end when the end has both add and disconnect 
activity occurring at it, an alternative match rule is used. The entire circuit ID is used. If the 
rule is met, the order, CKL, and item segments are updated with the design data. 


3. JOBID, CKL address and circuit ID (W3) 
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If the CKLID is not provided, the CKL address is used as an alternative match field for the CKL 
segment. It must be an exact match. The entire circuit ID is used. If the rule is met, the order, 
CKL, and item segments are updated with the design data. 


JOBID, circuit end, CKL action, and circuit ID (W4) 


If the incoming message does not provide a CKLID and the work request also does not have a 
CKLD, an attempt is made to match by the existing circuit end (A or Z) and CKL action. This 
reduces the number of items that may be erroneously built for that CKL if the CKLID is not 
involved in the match. The entire circuit ID is used. if the rule is met, the order, CKL, and item 
segments are updated with the design data. Communication with the Status Reporter is 
prevented since the CKLID is a required field for the status reporter interface. 


The circuit ID used via the index consists of two portions: a family portion and a segment 
portion. The family portion consists of the prefix, service code/modifier, area code, office, line, 
and extension for telephone formatted circuits, and a prefix, service code/modifier, serial number, 
and company code for serial number formatted circuits. The segment portion (segment ID) of the 
circuit identifies a particular segment of a circuit. Since the Service Order Interface only receives 
the family portion of the circuit ID, the designed data interface receiver module attempts to 
match first by the entire circuit ID, and secondly, by the family portion of the circuit ID. 


The same match attempts are made with the family portion of the circuit ID only. Trailing 
delimiters (’/’) are eliminated. 


JOBID, CKLID and circuit ID (F1) 

The family portion of the circuit ID is used. 

JOBID, disconnect CKL action and circuit ID (F2) 

The family portion of the circuit ID is used. 

JOBID, CKL address, and circuit ID (F3) 

The family portion of the circuit ID is used. . 
JOBID, circuit end, CKL action and circuit ID (F4) 

The family portion of the circuit ID is used. 

JOBID and CKL address (A) 


If none of the above match rules are met, an attempt is made to add the item at the correct 
location (CKL). if the CKL addresses match exactly, the item is added. GDMTCH can then be 
used to merge the correct items. 


Routing (RO) - If none of the above match rules are met, the message is routed to a GDS center 
utilizing GDICTR. If an order does not exist under that center, an order/CKL/item is added to 
the database. If an order already exists under that center, an additional CKL/item is added to 
the order segment. The CKL sequence number will be incremental from the last existing CKL 
segment. 


If the TIRKS table is logged in GDS, the Service Order Interface will attempt to match by the following 
criteria (in priority order): 


1. 


JOBID, CKLID, and circuit ID 
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2. JOBID, CKLID, and family portion of circuit ID 
3. JOBID and CKL address 
4. JOBID (a new CKL is created) 
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3.1.16 GDS-LMOS Interface 
A. Introduction 


The GDS-LMOS Interface provides the facility through which information about POTS and nondesigned 
special service trouble tickets, and loop testing is transferred between GDS and LMOS. The interface 
supports the following functions: 


e Transmission of trouble ticket data from LMOS to GDS. This includes both initial and subsequent 
trouble reports. Note that GDS is only interested in dispatchable troubles. The MOS screening 
function, used to determine dispatchability, continues to function as today. Once a ticket is 
identified by LMOS for outside dispatch, the trouble is sent to GDS via the RBOR transaction. The 
RBOR is initiated either automatically as part of an LMOS screening rule decision or manually by a 
user. Following BOR/MOR receipt, a DJI is requested to LMOS to obtain additional trouble data 
not available on the BOR/MOR. 


Transmission of status information from GDS to LMOS. This data is automatically sent "in the 
background" as the result of specified activities that occur in GDS. This provides the LMOS RSA 
with up-to-the-minute information about the status of trouble tickets. Additionally, data needed for 
TREAT processing is provided. GDS supports statusing for single jobs and stapled bundles. 


Transmission of closeout information from GDS to LMOS. This data is automatically sent "in the 
background” following the completion of a ticket. This provides LMOS with needed input for 
TREAT processing. 


Synchronization process to insure that GDS and LMOS maintain the same list of open troubles. 
This procedure is run automatically at user-defined intervals for a given maintenance center. The 
process will request the LMOS RCMD-DPJ (Display Pending Jobs) report and compare the active 
troubles in GDS and LMOS. For troubles open in LMOS but not GDS, an RBOR request is sent to 
LMOS to retrieve the relevant trouble data. Additionally, for cases where the subsequent counts of 
troubles open in GDS and LMOS do not match, an RBOR is requested to LMOS to obtain the most 
recent version of the trouble data. To utilize the synchronization feature, entries must be made in 
the GDCRON table and the TTS table GDS SYNCH OPTS. v 


Testing support for MLT loop and full tests and PST (list) processing. For more information on 
automatic loop testing, see the section entitled "Automatic Loop Testing.” 


B. Interface Architecture 
There are two alternative methods available for implementation of the GDS-LMOS Interface. Refer to 
Figure 3-6. 


The first architecture involves the implementation of an IBM Series 1 Machine referred to as a Link 
Processor (LP) that sits between the LMOS FES and the GDS Host. The Series 1 contains IBM and 
Bellcore developed software that provides protocol and format conversion as well as message routing 
functionality. 


The second architecture involves the implementation of DCOMM/TCIS software on the GDS Host. 
DCOMM/TCIS performs the same functions as the Link Processor, thereby eliminating the need for 
Series 1 hardware. 


Both architectures require the use of the Operation Interface (OI) software module on the GDS Host. 
OI provides the means through which the GDS application can communicate with LMOS. 
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For more information on OI, refer to 
e Operation Interface (OI) Administrative Guide, BR 190-539-009 ~ 
e Operations Interface (OI) On-Line Message Directory, BR 190-539-401 
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Figure 3-6. GDS-LMOS Interface Architecture 
C. Trouble Ticket Data 
The following lists the LMOS trouble ticket data used by GDS: 
TIN # 
UNIT # 
TN/CKTID 
CLASS OF SERVICE 


SERVICE CODE 
CUSTOMER NAME 
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CUSTOMER ADDRESS 
CUSTOMER LOCATION 
COMMITMENT DATE 
COMMITMENT TIME 
REACH CUSTOMER 
REPAIR ROUTE 

AFTER TIME 

BEFORE TIME 

ACCESS NARRATIVE 
PARTY POSITION NUMBER 
PRIORITY FLAGS : UP TO 5 OCCURRENCES 
TROUBLE DESCRIPTION 
PRIORITY RANKING 
RECEIVED DATE 
RECEIVED TIME 

LAST 1ST CODE 

LAST IST DATE 

LAST IST TIME 

SCREEN RESULT CODE 
SCREEN NARRATIVE 
SUBSEQUENT COUNT 
MLT VER CODE 

MLT TEST SUMMARY 


FOR F1 TO FZ 


COLOR 

TERMINAL ADDRESS 

CTTN 

MESSAGES : UP TO 2 OCCURRENCES 
GENERIC FIDS : UP TO 8 OCCURRENCES 
OS INDICATOR H 
DATE RECEIVED H 
DATE CLEARED | FOR UP TO THE LAST 
3 HISTORY ENTRIES 


ice] 
as) 


1 
i} 
TYPE 
DISPOSITION 
CAUSE 
REPAIRMAN 
HISTORY NARRATIVE 
PSO NO 

PSO DUE DATE 

USOC CODES : UP TO 12 OCCURRENCES 
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D. LMOS Statusing and Closeouts 


In GDS, whenever an LMOS-originated work request is restatused or completed, job status updates are 
sent to LMOS. A request is sent to LMOS through the OI (Operations Interface) subsystem. Three 
different OI request types, which correspond to three different LMOS transactions, are passed for these 
purposes: 

1. EST requests are passed when an LMOS work request is restatused in GDS. 

2. CEST requests are passed when the lead job of a stapled LMOS bundle is restatused in GDS. 


3. FST requests are passed when an LMOS work request is completed and a user provides FST data 
on the GDCOMP completion screen. 


After LMOS receives the request and processes it, if a processing failure of the GDS status change 
occurs, it will notify OI, which will then invoke a GDS transaction to inform GDS users of the 
processing failure. This transaction consists of two specific features: 


1. Exception notice printed to the appropriate GDS work location. 
2. An entry in the GDS Status Log database 


An exception notice to the appropriate work center that requested the status change will be printed. It 
will inform GDS users of the status failure on the LMOS front end. 


An entry event will be placed on the Status Log database as an Interface Error and will be displayed on 
the GDLOG screen. 


These functions occur "in the background" in that the user does not have to wait for LMOS to receive 
and process the status/closeout information before executing the next transaction. 


Table 3-7 presents a summary of the data transmitted. As illustrated on the table, designated GDS 
commands executed on GDS screens resulting in GDS status changes are to cause corresponding status 
changes in LMOS. When the appropriate status changes fail to be made in LMOS, the above described 
transaction will occur. This transaction thereby increases the likelihood that the GDS user can 
overcome the problem by entering the corrected data directly on the LMOS fdrmat in a more timely 
fashion. 


E. FAM Control 


The GDS-LMOS Interface functionality is controlled via the FAM (Feature Authorizations Module). 
For BCCs that have not funded the POTS feature set, the following are not accessible: 


e Trouble tickets with designated POTS classes of service will be prohibited from entry in GDS via the 
LMOS-GDS Interface. 


¢ MLT Tests and PST (list) processing are not permitted. 


For more information on FAM, refer to Section 3.1.10. 
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GDs LMOS 
STATUS CHANGE _ STATUS CHANGE 
GDs GDs 
SCREEN__ COMMAND _ FROM: TO: FROM: TO: 
GDDISP_ DISPATCH = (ANY) ~—s«DSP (ANY) DPO 
PREASSIGN PLD PRE PDO PRD 
REJECT DSP —- PLD DPO  PDO** 
REJECT DSP ss PRE DPO PRD 
REJECT DSP PSC DPO HLD 
REJECT DSP JEP DPO  -HLD 
GDCOMP —- RETURN DSP ——- PLD DPO  PDO** 
RETURN DSP PRE DPO PRD 
RETURN DSP JEP/PSC* = DPO.-—- HLD 
COMPLETE (ANY) CMP (ANY) (Note 1) 
GDMWR UPDATE (ANY) PLD (ANY) PDO** 
UPDATE (ANY) PSC (ANY) HLD 
UPDATE (ANY) JEP (ANY) HLD 
UPDATE (ANY) CAN No LMOS Notification 
GDTLOG = ADD PLD PRE PDO PRD 
DELETE PRE PLD PRD PDO** 
GDLST UPDATE PLD PRE PDO PRD 
UPDATE PLD PSC PDO  -HLD 
UPDATE PLD JEP PDO HLD 
ae GDLOAD — PERM PLD PRE PDO PRD 
CANCEL PRE PLD PRD PDo** 
GDGRP 
‘G'GROUPS ADD PLD GRP PDO PDO 
DELETE GRP PLD PDO PDO 
UPDATE GRP PSC PDO -HLD 
UPDATE GRP JEP PhO -HLD 
’S'}GROUPS DELETE STP PLD PDO PDO * 
DELETE STP PSC PDO -HLD 
DELETE STP JEP PDO -HLD 


* When using the RETURN Command and the JOBSTAT: JEP or PSC on the GDCOMP screen, the user can optionally enter 
data in the EST line fields. For example, if the work item is NO ACCESS SUBSCRIBER, the EST fie a court show 
WP: 0 IST: 070. The corresponding entries on the RST for that work item in LMOS would show: 


RMR (Repair Person Return) 
HLD (Hold) 
NAS (No Access Subscriber) 
If the EST data is not entered, the corresponding RST entries would show: 
“RMR (Repair Person Return) 
HLD (Hold) 
** PDO is only one of several possible LMOS "pending dispatch out” statuses. GDS saves the original "PDO" type (PDO, PDB, 
PDM) and uses it whenever a status needs to revert to "pending dispatch”. In the above examples, PDO is used to indicate 
any of the LMOS "Pending Dispatch Out” ISTs. 
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om, 


'L'GROUPS UPDATE ANY PLD ANY PDO 
UPDATE ANY PSC ANY = PSC 
UPDATE ANY JEP ANY __HLD 


Note 1: EST status used to clear a work item in LMOS. 
FST status used to close a work item in LMOS. 
In GDS, the EST and FST fields are user populated on the GDCOMP screen. 
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3.1.17 GDS - CIMAP/SSC Interface 


This section covers the Interface between CIMAP/SSC and GDS for Installation, Circuit History, and 
Maintenance. The Interface, for both Installation and Maintenance, provides a mechanized link 
between the Special Service Centers on CIMAP/SSC and the Dispatch Centers on GDS. 


A. GDS CIMAP/SSC - Installation Flows 


The CIMAP/SSC - GDS Installation Interface provides for the passing of CKL tracking information 
from GDS to the SSCs. Figure 3-7 shows the flow of information between the two systems. 


1. Information Flows for a Circuit Order Issue 


e CI/DIST at ISSUE passes order issue information to CIMAP/SSC. This information includes 
passing the WORD document to the CIMAP WORD databases and data to prime Circuit 
Installation and History databases. At RID completion GOC sends GOC CKL information to 
the Status Reporter. ° 


C1/DIST then notifies CIMAP/DOC which formats the information on the WORD into CIMAP 
documents for each CKL/CWL work location. CIMAP/DOC then passes the order issue 
information and CKL information to GDS. The information is matched with the data 
provided by SOAC. If it is an ESO/DSO, the data is used to build work requests. 


On receipt of this information, GDS transmits the following CKL information to CIMAP/SSC 
via the Status Reporter: 


— CKL location CLLI codes for all CKLs on GDS 
— CKL ID 


— Objective report dates 


— Tracking Flag setting indicating whether GDS will be completing work at a particular work 
location for DVA and Due Date. 


The users on CIMAP/SSC can view this information and make status checks via the OSSCWL 
screen. This format displays all CWL/CKL locations that are logged in the IA database by 
GOC, CC, and GDS. The CKL information is placed on the CIMAP/SSC LOG if the option is 
set to “Yes” in the SSC-OPTIONS table. 


2. CWL/CKL Matching 


— The matcher algorithm in CIMAP is responsible for matching GDS CKLs with GOC 
CKLs/CWLs. See section D for details on this algorithm. As a result of the matching process, 
the Status Reporter knows which GOC CKL to post when a CKL completion is received from 
GDS. 


— The GDS users must make sure that the CKL ID logged on LOOP2 is the same as the CKL ID 
logged in GOC if matching of GOC/GDS CKLs is to function correctly. 


3. Posting Information for CKL level dates 


— The OSSCWL screen displays the CKL jeopardies, jeopardy removals, and date completions 
passed by GDS to both CIMAP/SSC and GOC via the Status Reporter. After logging the 
CKL locations in the IA database, GDS autocompletes DVA at the CKL locations for jobs with 
a status of pending load (PLD) or pending auto complete (PAC). Work Requests are built in 
GDS and placed in a dispatch work pool. When the dispatch work is completed, GDS posts the 
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CKL DD completions to the Status Reporter. The Status Reporter informs CIMAP/SSC of the 
completion which is displayed on OSSCWL and also sends the completion to GOC if the GDS 
locations are matched with a GOC CWL. LOG entries for all postings are made if the option 
is set to "Yes" in the SSC-OPTIONS table. 


CIMAP/SSC can manually add CKL locations on the OSSCWL format. Completions and 
jeopardies can be posted for these manually added locations from OSSCWL, and for GOC 
CKLs/CWLs that are not tracked by GDS. 


The SSC will post item level date completions after all work at the CKL/CWL level has been 
completed. Item level date completions will be blocked if there is outstanding work at the 
CKL/CWL level. The final step is posting DD completions after all work associated with 
installing the circuit is finished and the service is accepted by the customer. 


The Status Reporter notifies GDS that the circuit is In-Effect (IE). GDS then passes Circuit 
History information for the circuit end locations to CIMAP/SSC. This information is placed in 
the Operations Circuit History database. This activity is explained in detail in the next 
section. 
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Figure 3-7. GDS-CIMAP/SSC Installation Interface 
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B. GDS CIMAP/SSC - Circuit History Flows 


GDS receives designed special service information from both the TIRKS System and SOAC. This 
information is combined to produce dispatch work details for each circuit termination. When the circuit 
is completed in GDS and goes in-effect (IE) in SSC, GDS will pass circuit and CKL dispatch information 
to CIMAP/SSC. The information will be stored in the Circuit History database. GDS will perform 
validation to insure that the required fields are populated. These fields can be displayed on the 
CIMAP/SSC: Circuit History Update (OSSCHU). 


When a Trouble Report is handed off to GDS, the MT in the SSC will identify the CKL (circuit 
termination - A or Z) at the time of the handoff. CIMAP/SSC will retrieve the appropriate circuit 
termination information needed by GDS for dispatch from Circuit History and append the information 
to the Trouble Report before sending the trouble to GDS. If any fields required for dispatch are 
missing, an error message will be returned to the user’s terminal. HELP (PF9) lists for the user all 
required fields. The missing data can be updated on OSSCHU or OSSTR and the handoff can then take 
place. At the time of the completion of the handoff by GDS, circuit history information is returned to 
CIMAP/SSC with all the required fields populated. Included are any updates on the information done 
while the trouble was dispatched. The information is again stored in the Circuit History database. 


Table 3-8 lists all the circuit history fields that are passed between CIMAP/SSC and GDS. The table 
includes the FID names in each system, the data source at the time of order completion, and a field 
description. 
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Table 3-8. Circuit History Fields and Primary Data Source. 


SYSTEM 
ssc Gbps source!) DESCRIPTION 
(OSSCHU) (GDMSWR/GDISWR) 
CKT CKTID TIRKS Circuit ID 
CSC CSC (2) GDS (SOAC) Class of Service Code (SVC/MOD) 
CAC CAC TIRKS Circuit Access Code 
CUS NAME BILL NAME TIRKS Billing Customer Name 
TEL TEL TIRKS Billing Telephone Number 
CKLLOC co TIRKS Local Serving Office CLLI Code 
RSP/TSP TSP TIRKS Restoration Priority 
ACNA CNA TIRKS Access Carrier Name Abbr. 
wc wc GDS (SOAC) P1-P2 Wire Center 
* CKL NAME CKL NAME GDS (SOAC) or TIRKS CKL Customer Name 
CKL TEL CKL TEL GDS (SOAC) or TIRKS CKL Customer Telephone Number 
* CKL ADDR CKL ADDR GDS (SOAC) or TIRKS CKL Customer Address 
LOC Loc GDS (SOAC) CKL Customer Location 
NCI NCI GDS (SOAC) Network Channel Interface 
DAA/AA DAA/AA GDS Dispatch Administration 
Area/Allocation Area 
RTE RTE GDS Route Code 
* FAC FAC GDS (SOAC) Local Facility Identifier 
* CABLE CABLE GDS (SOAC) Local Facility Cable 
* PAIR PAIR GDS (SOAC) Local Facility Cable Pair 
BP BP GDS (SOAC) Local Facility Binding Post 
COLOR COLOR GDS (SOAC) Local Facility Pair Color 
TERM ADDRESS TERM ADDRESS GDS (SOAC) Local Facility Terminating Address 


y 


* Fields required in SSC to perform a handoff to GDS. 


Note (1): The Source Column indicates those system(s) which are responsible for the fields that are 
required to build a circuit record within circuit history at time of Service Order Completion. 


Either system can be the primary data source. The source is determined by the information 
which was received last. 


(2): GDS (SOAC) indicates that the information stored in circuit history was received from GDS 
and GDS obtained the data from SOAC. 


C. GDS CIMAP/SSC - Maintenance Flows 


The GDS CIMAP/SSC - Maintenance Interface provides the means for a mechanized handoff of Special 
Services Trouble Reports for field dispatch. It supports a fully automated trouble handoff, update, and 
completion process between CIMAP/SSC and GDS. (see Figure 3-8) 


This maintenance interface uses the information stored in the Circuit History database. Upon 
completion of a service order, a circuit record is built containing all the CKL (circuit termination 
location - A or Z) information necessary to perform a field dispatch. 
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When a handoff for. dispatch (HDD) is performed by CIMAP/SSC, the CKL information is 
automatically retrieved from the CKT HIST database and passed to GDS, along with selected 
information from the customer Trouble Report. 


This interface will support an automatic handoff process which includes the following: 
« Passing of intermediate and final status of dispatched trouble tickets from GDS to SSC. 
e Acomplete mechanism for trouble ticket tracking in either of the two systems. 
e Mechanized closeout from either CIMAP/SSC or GDS. 

The following interface message types are passed between CIMAP/SSC and GDS: 


HANDOFF - Indicates a trouble report is being handed off for a field dispatch from SSC. GDS 
responds back to SSC with a negative or positive acknowledgement. 


UPDATE - Used when a trouble has already been passed to GDS and an addition or change to 
the delayed maintenance or no access fields is made. GDS uses the update message 
to inform SSC of changes in job status (i.e., DSP). 


REMARK - Remarks are passed to GDS from SSC on a handoff or a DM/NA. GDS can also 
pass remarks to SSC by using the update function on the GDCOMM screen. 


CANCEL - Used to inform the other system of the cancellation when a trouble has been handed 
off to GDS for dispatch and it is cancelled by CIMAP/SSC or GDS. 


TRANSFER - Used to update information in CIMAP/SSC when a trouble ticket is moved from one 
GDS center to another. 


COMPLETE -_ Used when a trouble ticket has been completed in GDS, or completed by SSC. 
D. Trouble Report Handoff (HDD) 


When a special service trouble has been tested and it is determined that a field dispatch is required, the 
MT populates the following information on OSSTR (or OSSTGM): 
1. FCT HDD Handoff to dispatch 
2. DESTINATION The CLLI code location (e.g., center or work 
location) of the work group to receive the handoff. 
If the CLLI code is in the VALID SSDAC LOC table 
in CIMAP/SSC, then the HDD is a mechanized 
handoff to GDS. 
3. END The CKL end needed for dispatch (e.g., A/P1, Z/P2) 
4. SDATE/STIME Start and End Dates/Times 
EDATE/ETIME (Defaults are available). 


CIMAP/SSC sends the trouble to GDS with the appropriate circuit history information for the circuit 
termination. GDS will first check to see if a work request exists for the JOBID and end (A or Z). 


If no such work request. exists, GDS checks to see if circuit history fields needed for dispatch are missing. 
If so, the handoff will be blocked until the fields are updated. GDS receives the trouble and builds a 
maintenance work request. A positive acknowledgment is returned to CIMAP/SSC with the SSDASC 
center responsible for fixing the trouble and the CKLW assigned within the center (either "O1" or "O2"). 
The center appears in the "HO Center" on the OSSTR screen. If the work request fails job logging it is 
placed in pending screen status (PSC); otherwise, it is placed in pending load status (PLD). For a 
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negative acknowledgment, no center or CKL is assigned and no work request is built. A message 
explaining the reason that the handoff failed is placed on the OSSLOG, and the handoff is cancelled. 


If a previous work request exists for the JOBID and end, GDS will check to see if CKT FMT, CKTID, or 
SSC differ between the existing work request and the fields in the handoff message. If any of these 
fields differ, GDS will reject the handoff and send a negative acknowledgment to SSC. The negative 
acknowledgment will specify which field, CKTFMT, CKTID, or SSC that is different. A GDS exception 
notice number 311 will be sent to the printer or Iterm specified in the "GDS EXCEPTIONS" TTS table 
for the GDS center owning the existing work request. 


If CKT FMT, CKTID, and SSC match, the existing GDS work request is cancelled or completed, and 
the handoff destination is a different GDS center, it is treated as a new handoff and processing will 
continue as if GDS does not: have a work request for this JOBID/end combination. If CKT FMT, 
CKTID, and SSC match, the existing GDS work request is cancelled or completed, and the handoff 
destination is the same GDS center, then all fields in the handoff message are moved to the appropriate 
fields in the existing work request and the "REPEAT-REPORT" flag for the work request is set to yes. 
The date and time received by GDS are NOT updated. The work request is job-logged using the new 
data values, and a normal positive or negative acknowledgment to an SSC handoff attempt is sent to 
SSC and displayed on OSSLOG. 


If CKT FMT, CKTID, and SSC match, but the existing GDS work request is not cancelled or completed, 
and the work request was added manually in GDS, the "NOTIFY" flag is set to yes to enable further 
GDS-SSC communication, and the message "SSC HANDOFF ESTABLISHED ON MANUALLY-ADDED 
JOB" is placed in the work request comments field. If the work request was previously handed off, the 
message "SSC REESTABLISHED HANDOFF MADE PREVIOUSLY" is placed in the comments field. In 
both cases (a manually added or previously handed off work request), all values from the handoff 
message fields are moved into the work request, with the exception that the wire center and route field 
are only moved in when the message fields are non-blank and the work request fields are blank. Since 
the work request might be in any status at this time (e.g., DSP, PRE, etc.), a positive acknowledgment 
is sent to SSC with one of the following messages as appropriate: 


"PREVIOUS SSC HANDOFF REESTABLISHED" 5 
"HANDOFF ESTABLISHED ON JOB ADDED MANUALLY IN GDS" 
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Figure 3-8. GDS CIMAP/SSC - Typical Interface Maintenance Work Flow 
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1. Remarks and DM/NA Information 


Remarks and DM/NA information are passed between CIMAP/SSC and GDS during a handoff. 


a. Remarks - At the time of the handoff, CIMAP/SSC sends up to 200 characters of remarks 
with the use of the "RMK" or “DMK" (Dispatch Remarks for GDS) function. Once the 
handoff to GDS has been accomplished, the "RMK” function will no longer pass remarks to 
GDS. Additional remarks may be passed to GDS using the "DMK" function. This function 
will pass remarks as long as the handoff of the Trouble Report has not been completed. 
When a DM/NA is performed in CIMAP/SSC during the handoff, the remarks associated 
with the DM/NA will only be passed when using the "DMK" function. These remarks will be 
sent to GDS and will be added to the work request comments field provided the size of that 
field is not exceeded. Remarks can be sent to CIMAP/SSC from the GDS format GDCOMP. 
The GDS users can send up to 40 to 50 characters of narrative in the RET JOB NARR field, 
depending on the command being performed. Only 40 characters of remarks are sent to 
CIMAP/SSC when performing the commands of COMP or RET on the GDCOMP format. 
When using the UPDATE command a total of 50 characters of remarks are sent to 
CIMAP/SSC. CIMAP/SSC will place the GDS remarks in the Log. 


b. DM/NA Information - CIMAP/SSC will send GDS the DM or NA start and end times if a 
DM/NA is active at the time of the handoff. If a DM/NA is not currently active but there 
is a DM/NA that will start in the future, those start and end times will be sent. Any 
subsequent updates or cancels of the DM/NA in CIMAP/SSC will also be sent to GDS. On 
the GDMSWR format, a DM/NA interval may be established by a GDS user through an add 
or cancel of a work request or an update of the interval fields. On the GDMSCP format, a 
DM/NA interval may be established or modified by a GDS user when a job is returned or 
completed. The DM/NA interval may also be modified when a job is dispatched to a 
technician on GDMSDP. 


It is recommended that CIMAP/SSC users not add both a DM and an NA on a Trouble 
Report, although the timers do not overlap, as GDS only has room ta,store one interval at a 
time. 

While a DM/NA interval specified by a "FROM-TO" date and time pair restricts automatic 
dispatch, the presence of any DM/NA interval will not prevent a manual dispatch. 


In order to provide better user analysis of key maintenance duration intervals of SSC jobs in 
GDS, the following six calculated duration fields are provided in TQS: 


TQS NAME DESCRIPTION 

1. RCP_T_DSP_NA DM time from receipt in GDS to first dispatch 

2. DSP_T_CLR_NA DM time from first dispatch to restoral 

3. TOT.DMNA_TM _ Total DM time from receipt in GDS to restoral 

4. RCPT_TO-CLR Time from receipt to restoral minus the TOT_.DMNA_TM value 

5. RCPT_TO_DSP Time from receipt to first dispatch minus the RCP_T_DSP_NA value 
6. DSP_TO_CLR Time from first dispatch to restoral minus the DSP_T_CLR_NA value 
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The following No-Access Interval fields are used in calculating the previously described 
duration fields: 


TQS NAME DESCRIPTION 


DM_NA FLAG _ Flag indicating "DM" or "NA" 
NA.FROM_DT DM/NA "From" Date 
NA.FROM_TM DM/NA “From” Time 
NA_TO_DT DM/NA "To" Date 
NA_TO_TM DM/NA "To" Time 


The four fields listed below are used as Interval Endpoints in the calculations of the duration 
fields: 


TQS NAME DESCRIPTION 


GDS_RCVD_DT Date first handoff received in GDS 
GDS_RCVD_TM _ Time first handoff received in GDS 
RESTORED_DT Date service restored to customer 
RESTORED_TM _ Time service restored to customer 


Several other TQS fields are involved in the calculations: 
TQS NAME DESCRIPTION 


#DSP # times job dispatched out 

RETURN_DATE Date technician returned job 

RETURN_TIME _ Time technician returned job 

BEGIN_DATE Date technician started work on job 
BEGIN_TIME Time technician started work on job = 


The methods used for calculating and populating the SSC duration fields are detailed below. 
In all instances, if a DM/NA interval ends before the first handoff of a job from SSC is 
received in GDS, no DM/NA time will be accrued and all DM/NA interval fields will be 
blanked out. 


When a Job is Dispatched 
Several different processes occur which affect the population of the SSC maintenance duration fields. 


— No DM/NA time will be accrued if the interval start time is later than the CURRENT time of the 
dispatch. All interval fields will be left as they are on the work request. 


— If this is the first dispatch (#DSP field = 1), any portion of the interval which falls between the time 
the handoff was first received in GDS and the CURRENT time will be added into the 
RCP_T_DSP_NA field. If this is the second dispatch or greater, any DM/NA between the time the 
handoff was received in GDS and the time that service is restored will be put into DSP_T_CLR_NA. 


— Any portion of the interval which extends past the CURRENT time will be left intact. A revised 
DM/NA interval results when an interval overlaps the CURRENT time because the "FROM" 
date/time is replaced with the CURRENT date/time, while the "TO" date/time remains the same. 
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— If this is a first dispatch, the RCPT_TO_DSP value will be calculated as CURRENT time minus the 
time the handoff was received in GDS minus any DM/NA that occurred between the receipt and the 
first dispatch: 


RCPT_TO_DSP = CURRENT - GDS_RCVD (_DT/_TM) - RCP_T_DSP_NA 


It is possible that RCP_T.DSP_NA may have a value from a previous rejected dispatch. 
RCPT_TO_DSP will not be allowed to be a negative value and will be zeroed in this case. 


When a Job is Rejected 
RCPT_TO_DSP will be zeroed if this was the first dispatch (#DSP = 0). 
When a Job is Returned 


Several processes occur that affect the population of the SSC calculated duration fields if a DM/NA 
interval is present. 


— No DM/NA time will be accrued if the interval starts after the job return date/time and the 
interval will be left intact. 


— On the first dispatch, any portion of the DM/NA interval that falls before the BEGIN_.DATE/TIME 
will be added into the RCP_T_DSP_NA field. 


— Any part of the interval that falls between the time that work is begun on the job and the time the 
job is returned will be added into the DSP_T_CLR_NA field. 


— Any portion of the interval after the RETURN_TIME will be left on the job, with the 
RETURN_TIME replacing the previous "FROM" date/time, thus creating a new interval which 
begins at the time the tech returned the job. 


When a Job is Completed by a Technician 
Several processes occur that affect the population of the SSC calculated duration fields. 


— As previously described under a returned job, on the first dispatch any portion of the DM/NA 
interval that falls before the date/time that the technician begins work on the job will be added into 
the RCP_T_DSP_NA field. 


— The DSP_T_CLR_NA field will include any part of the interval that falls between the time that the 
technician begins work on the job and the time that the service is restored to the customer. 


— Any portion of the DM/NA interval which falls after the RESTORED_TM will not be accrued. 
However, in the event that a job is reopened by SSC, this interval will be left on the job. 


— The following fields will be set: 


e The total amount of DM/NA time on a job will be equal to the sum of the DM/NA time accrued 
between the receipt and the first dispatch and the DM/NA time accrued between the first 
dispatch and the restoral time. 


TOT_DMNA_TM = RCP_T_DSP_NA + DSP_T_CLR_NA 


e The RCPT_TO_CLR value will be set to the restoral time minus the handoff receipt time minus 
the total amount of DM/NA time between the receipt and the restoral. 


RCPT_TO_CLR = RESTORED_TM - GDS_RCVD_TM - TOT_DMNA_TM 
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e The DSP_TO_CLR value will be set to the RCPT_TO_CLR value minus the RCPT_TO_DSP 
value. 


DSP_TO_CLR = RCPT_TO_CLR - RCPT_TO_DSP 


When a Non-Dispatched Job is Completed or Cancelled (vis GDCOMP, GDMSWR, or an 
SSC interface request) 


Several processes occur that affect the population of the maintenance duration fields if a DM/NA 
interval is present. 


— If a job was never dispatched, any part of the DM interval between the handoff receipt time in GDS 
and the CURRENT time will be added to the TOT.DMNA_TM field. (If completed via GDCOMP, 
RESTORED_TM will be used instead of CURRENT time.) 


— If a job had been previously dispatched, any part of the same interval will be added to the 
DSP_T_CLR_NA field. 


— Any portion of the interval which falls after the CURRENT time will be left intact in the event that 
the job is reopened by SSC. (Again, if completed via GDCOMP, RESTORED_TM will be used 
instead of CURRENT time.) 


— If the job was previously dispatched, the following fields will be set: 


RCPT_TO_CLR = RESTORED_TM - GDS_RCVD_TM - TOT_.DMNA_TM 
(use CURRENT instead of RESTORED_TM if not from GDCOMP) 


TOT_DMNA_TM = RCP_T_DSP_NA + DSP_T_CLR_NA 
DSP_TO_CLR = RCPT_TO_CLR - RCPT_TO_DSP 


— If the job was never dispatched, any time in RCP_T_DSP_NA (from a rejected dispatch) will be 
added to TOT.DMNA_TM and RCP_T_DSP_NA will be zeroed out. The RCPT_TO_CLR field will 
be set in this case exactly as above, using CURRENT time in its calculation if it is other than a 
completion from GDCOMP. 7 


RCPT_TO_CLR = RESTORED_TM - GDS_RCVD_TM - TOT_.DMNA_TM 
(use CURRENT instead of RESTORED_TM if not from GDCOMP) 


When an Update is Received Through the SSC Interface 


Several processes occur that affect the population of the SSC duration fields if a DM/NA interval is 
present. 


— The interval fields on GDMSWR will be populated with the new DM/NA interval values if no 
interval is present on the work request at the time of the update receipt. No other fields will be 
updated. 


— When an interval already exists, if the update DM/NA flag value matches that of the current 
interval (ie., previous interval was a DM condition and update is a DM condition or previous 
interval was an NA condition and update is an NA condition), the new interval values will replace 
the existent values in the work request interval fields. This situation could effectively cancel the 
previous DM or NA interval if the update contains all blanks. No other fields will be updated. 


— When an interval already exists and the updated DM/NA flag value is different from the previous 
(e.g., old = DM and new = NA), several different processes will occur depending on whether or not 
the old interval has expired. 
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e When the old interval has expired and the job has not yet been dispatched, any portion of the 
old interval that falls between the handoff receipt time and the CURRENT time will be added to 
the RCP_T_DSP_NA field. If the old interval has expired and the job has been dispatched, that 
same portion of the old interval will be added to the DSP_T_CLR_NA field. The new interval 
fields will then be moved into the interval fields on the work request. 


In the situation where the old interval has not yet expired, the old interval will be left as is. A 
narrative describing the new interval will be placed in the work request COMMENTS field. The 
system message flag will be set to "Y" to ensure that a GDS user sees the comments by 
automatically jumping to the GDCOMM screen upon an attempt to dispatch or complete the job. 


** When the first interval is no longer operational, the user must manually update the interval 
fields on GDMSWR with the values shown in the COMMENTS field. However, to ensure that 
the first interval is accounted for in the appropriate duration field(s), it is important that 
the first interval be processed using normal methods - i.e., handled at the time of dispatch, reject, 
return, etc. as described above. 


2. Cancellation of Handoffs 


Trouble Reports handed off to GDS may be cancelled by CIMAP/SSC or GDS. After CIMAP/SSC 
performs a handoff to GDS, SSC can cancel it by using the "ACN" function on the OSSTR screen. 
The status of the Trouble Report in SSC will revert to the status it had prior to the handoff. A 
message will be printed in SSDAC informing the center of the pending cancellation. When GDS 
receives this cancellation message and the trouble ticket has a status of PRE/PLD, the job is 
automatically cancelled and removed from the GDS work list. If the job is dispatched (job status 
of "DSP") the work request will remain in dispatch status until the job is complete and the 
technician’s time applied to the job. GDS will send a completion message to SSC which will not 
be acknowledged. 


When the SSC user needs to re-establish a handoff on a GDS trouble ticket with a status of "DSP" 
(dispatched), the SSC user should perform another handoff (HDD) on the Trouble Report 
dispatched in GDS. GDS will acknowledge the handoff and match the existing GDS (dispatched) 
trouble ticket with the new request. GDS adds a message to GDCOMM indicating that the 
handoff was re-instated by SSC. GDS returns to CIMAP/SSC a positive acknowledgement of the 
handoff which is placed in the Trouble Report’s log. 


GDS can cancel a handoff from SSC when it performs the cancellation message of "CAN". The 


handoff will be completed in SSC. The status of the Trouble Report will be its status prior to 
handoff. SSC will place an entry on the OSSLOG of "SDX" meaning GDS cancellation. 


The third type of cancellation happens when CIMAP/SSC sends a handoff message to GDS. GDS 
does not accept this message and sends back to SSC a negative acknowledgement. message. Upon 
receiving the negative response, SSC cancels the handoff to GDS. The status of the Trouble 
Report reverts to the status prior to handoff. The Trouble Report will be either placed in the pool 
for pickup or returned to the MT performing the handoff to GDS. The OSSLOG entry will be 
"HON" indicating an automatic cancellation of the handoff. 


E. Move to Another Center 


GDS can transfer a trouble ticket from one GDS center to another GDS center after receiving it from 
SSC. This transaction is accomplished when a user performs a "MOVE" command on a trouble ticket. 
A message is sent to SSC containing the Old and New center. When SSC receives this message it 
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displays the new center in the "HO Center" field on the OSSTR screen, SSC will also place an entry on 
the OSSLOG of "SDT" indicating a transfer of centers in GDS. 


F. Grouped Trouble Reports 


Trouble Reports (TRs) which are grouped in CIMAP/SSC will be passed to GDS as individual trouble 
tickets. CIMAP/SSC will maintain the group but, due to the following reasons, the group must be 
unbundled before GDS will accept the handoff message: 


e GDS may or may not be able to dispatch all the tickets as a group. 


e Each trouble ticket has different circuit termination information. When handing off a group of TRs 
for dispatch, the CKL termination information must accompany each individual TR in the group. 


CIMAP/SSC passes the Group ID for every grouped trouble to GDS where it is placed in the comment 
field of its trouble tickets for reference. 


G. Handoff Completion 


When the technician completes the trouble ticket, the completion information is given to the dispatcher 
for input on the completion format GDCOMP. The GDS work request is completed (job status = 
“CMP"). 

When GDS completes a handoff, a number of conditions exist concerning the completion process between 
GDS and CIMAP/SSC. The conditions are as follows: 


e The trouble ticket is completed in GDS, job status becomes "CMP", a completion message is sent to 
SSC, and the Restored To (RST_TO) field on GDCOMP screen is blank. SSC completes the HDD 
and makes it available for pickup in the pool. 


The trouble ticket is completed in GDS, job status becomes "CMP", a completion message is sent to 
SSC, and the Restored To (RST_TO) field on GDCOMP screen ts not blank. 


— There is an automatic restoral option (AUTO-RST) in the TTA OPTIONS table in CIMAP/SSC. 


— If the AUTO-RST switch is set to "Yes", indicating that an automatic festoral is allowed, the 
Trouble Report is restored in CIMAP/SSC, with the restoral information provided by GDS. 


— If the switch is set to "no", the handoff is completed, the TR is not restored, and is made 
available for pickup in CIMAP/SSC. 


If the field technician closes out the Trouble Report while working with a MT via a telephone call, 
CIMAP/SSC allows the MT to complete the handoff and restore the Trouble Report although it has 
a HDD status in CIMAP/SSC and a job status of DSP in GDS. The technician must still provide 
completion data to the dispatcher and return the job. This restoral will complete the HDD; 
however, CIMAP/SSC will accept any subsequent completion message from GDS and perform any 
required CKT/HIST updates. 


H. Smart JUMP/FINDs 


The Smart Jump/Find feature allows the GDS user the accessibility to both systems, CIMAP/SSC and 
GDS. This feature is allowed through the format access, transaction definition, and S1 security of both 
CIMAP/SSC and GDS software. The GDS users will have to be added to the CIMAP SI security 
database using VOSIADM before CIMAP/SSC will allow access to its format library. The GDS user 
will sign onto the GDS system using VGSISIGN. The user must then sign on to CIMAP/SSC System 
using VOSISIGN. The user now has access to both CIMAP/SSC and GDS. Only those fields located on 
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the SSC’s formats which are pertinent to a GDS user will be passed to GDS. See Table 3-9 for those 
SSC formats accessible to the GDS user. 


Table 3-9. CIMAP/SSC Formats Which A GDS User May Request Using the SMART JUMP/FIND 


Feature 
SSC FORMAT DESCRIPTION 
OSSEVT Event Definition 
OSSAVL Maintenance Work List 
OSSWPS Work Position Entry 
OSSLAC LMOS Work Activity 
OSSCCP CIMAP/CC Pool Work List 
OSSLOG Work Log 
OSSLST Installation Work List 
OSSPND Pending Trouble List 
OSSOI Order Information 
OSSCWL Order-CWL Information 
OSSOID Order Item Display 
OSSCHI Circuit History 
OSSHMD History Measurement Data 
OSSML Multipoint Circuit List 
OSSPID Administration Partial Circuit ID 
OSSTRE Trouble Report Entry 
OSSLTR LMOS Trouble Report/Activity 
OSSIMD Installation Measurement Data 
OSSTR Trouble Report/Activity 
OSSCL CLO Lost by Order 
OSSTGS Trouble Group Scan 
OSSTGM Trouble Group Maintenance 
OTRIO1 Test Details Results- Intra-LATA CKTs 
OTRLOL Test. Details Results- LATA Access CKTs 
OTOLO1 Test Details Objectives- LATA Access CKTs 
OTOI01 Test Details Objectives- Intra-LATA CKTs 
OSSBOR LMOS Basic Output Report 
OSSRST LMOS Trouble Report Status 
OSSCPR Circuit Purification Reconciliation 
ORAPDS Access Point Data 
OWDDOC WORD Display 
OSSCN Circuit Notes 
OSSGI Grouping Information 
OSSCHU Circuit History Update 
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KSETFEAT (ACDNR) 
KSETFEAT (ACOU) 
KSETFEAT (ACRJ) 
KSETFEAT (AFC) 
KSETFEAT (AIN) 
KSETFEAT (AOC) 
KSETFEAT (AR) 
KSETFEAT (ASL) 
KSETFEAT (ASP) 
KSETFEAT (AUD) 
KSETFEAT (AUL) 
KSETFEAT (AUTODISP) 
KSETFEAT (BBGI) 
KSETFEAT (BC) 
KSETFEAT (BCLID) 
KSETFEAT (BLF) 
KSETFEAT (CCV) 
KSETFEAT (CCBS) 
KSETFEAT (CFB) 
KSETFEAT (CFD) 
KSETFEAT (CFDVT) 
KSETFEAT (CFFPOVR) 
KSETFEAT (CFTB) 
KSETFEAT (CFTD) 
KSETFEAT (CRUIF) 
KSETFEAT (CFX) 
KSETFEAT (CFXDNCT) 
KSETFEAT (CFXVAL) 
KSETFEAT (CIDSDLV) 
KSETFEAT (CIDSSUP) 
KSETFEAT (CIF) 
KSETFEAT (CLI) 
KSETFEAT (CNF) 
KSETFEAT (COT) 
KSETFEAT (CPR) 
KSETFEAT (CPU) 
KSETFEAT (CRBL) 
KSETFEAT (CSMI) 
KSETFEAT (CTD) 
KSETFEAT (CUG) 
KSETFEAT (CW) 
KSETFEAT (CWD) 
KSETFEAT (CWT) 
KSETFEAT (CXR) 
KSETFEAT (DASK) 
KSETFEAT (DBC) 
KSETFEAT (DCC) 
KSETFEAT (DCPK) 
KSETFEAT (DDI) 
KSETFEAT (DIN) 
KSETFEAT (DMCT) 
KSETFEAT (DND) 


Automatic Call Distribution Not Ready (Feature ACDNR) Subtable 
Additional Call Offering - Unrestricted (Feature ACOU) Subtable 
Anonymous Caller Rejection (Feature ACRJ) Subtable 

Additional Functional Calls (Feature AFC) Subtable 

Advanced Intelligent Network (Feature AIN) Subtable 

Advice of Charge (Feature AOC) Subtable 

Automatic Recall (Feature AR) Subtable 

Agent Status Lamp (Feature ASL) Subtable 

Alternate Service Provider (Feature ASP) Subtable 

Automatic Dial (Feature AUD) Subtable 

Automatic Dial (Feature AUL) Subtable 

Automatic Display (Feature AUTODISP) Subtable 

Basic Business Group ISDN (Feature BBGI) Subtable 

Bearer Capability (Feature BC) Subtable 

Bulk Calling Line Identification (Feature BCLID) Subtable 

Busy Lamp Field (Feature BLF) Subtable 

Call Covering (Feature CCV) Subtable 

Call Completion to Busy Subscriber (Feature CCBS) Subtable 

Call Forward Busy (Feature CFB) Subtable 

Call Forward Don't Answer (Feature CFD) Subtable 

Call Forward Don't Answer Variable Timer (Feature CFDVT) Subtable 
Call Forward Fraud Prevention Override (Feature CFFPOVR) Subtable 
Call Forward Timed for CFB (Feature CFTB) Subtable 

Call Forward Timed for CFD (Feature CFTD) Subtable 

Call Forward Universal Intragroup Fixed (Feature CRUIF) Subtable 
Call Forwarding (Feature CFX) Subtable 

Call Forwarding per DN per Call Type (Feature CFXDNCT) Subtable 
Call Forwarding Validation (Feature CFXVAL) Subtable 

Caller ID Delivery and Suppression Delivery (Feature CIDSDLV) Subtable 
Caller ID Delivery and Suppression (Feature CIDSSUP) Subtable 
Controlled Interflow (Feature CIF) Subtable 

Calling Line Identification (Feature CLI) Subtable 

Flexible Station-Controller Conference (Feature CNF) Subtable 
Customer Originated Trace (Feature COT) Subtable 

Datapath Call Path Restoration (Feature CPR) Subtable 

Call Pickup (Feature CPU) Subtable 

Call Reference Busy Limit (Feature CRBL) Subtable 

Call Screening, Monitoring, and Intercept (Feature CSMI) Subtable 
Carrier Toll Denied (Feature CTD) Subtable 

Closed User Group (Feature CUG) Subtable 

Call Waiting (Feature CW) Subtable 

Dial Call Waiting (Feature CWD) Subtable 

Call Waiting (Feature CWT) Subtable 

Call Transfer (Feature CXR) Subtable 

Display Agent Status Key (Feature DASK) Subtable 

Call Reference Busy Limit (Feature DBC) Subtable 

Deactivate Conference Facility (Feature DCC) Subtable 

Directed Call Park (Feature DCPK) Subtable 

Direct Dialing In (Feature DDI) Subtable 

Denied Incoming (Feature DIN) Subtable 

Deny Malicious Call Termination (Feature DMCT) Subtable 

Do Not Disturb (Feature DND) Subtable 
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KSETFEAT (DQS) 
KSETFEAT (DQT) 
KSETFEAT (DRING) 
KSETFEAT (DROP) 
KSETFEAT (EBO) 
KSETFEAT (ECM) 
KSETFEAT (EMK) 
KSETFEAT (EMW) 
KSETFEAT (FAA) 
KSETFEAT (FC) 
KSETFEAT (FCTDINT) 
KSETFEAT (FXR) 
KSETFEAT (GIAC) 
KSETFEAT (HF, 
HFMUTE, MUTE, 
SOFTKEY) 

KSETFEAT (ICM) 
KSETFEAT (INSPECT) 
KSETFEAT (ISA) 
KSETFEAT (JOIN) 
KSETFEAT (KSH) 
KSETFEAT (LMOH) 
KSETFEAT (LOB) 
KSETFEAT (LOCAL) 
KSETFEAT (LPIC) 
KSETFEAT (LSPSO) 
KSETFEAT (LVM) 
KSETFEAT (MBSCAMP ) 
KSETFEAT (MCH) 
KSETFEAT (MCT) 
KSETFEAT (MIPHONE) 
KSETFEAT (MRFM) 


KSETFEAT (MSB) 
KSETFEAT (MWIDC) 
KSETFEAT (MWORY) 
KSETFEAT (MWT) 
KSETFEAT (NDNAP ) 
KSETFEAT (NGTSRVCE) 
KSETFEAT (NRS) 
KSETFEAT (OBS) 
KSETFEAT (OLS) 
KSETFEAT (PBL) 
KSETFEAT (PCACIDS) 


KSETFEAT (PF) 

KSETFEAT (PIC) 
KSETFEAT (PRK) 
KSETFEAT (PRL) 
KSETFEAT (PRV) 
KSETFEAT (QBS) 
KSETFEAT (QCK) 
KSETFEAT (QTD) 
KSETFEAT (RAG) 
KSETFEAT (RMB) 
KSETFEAT (RSUS) 
KSETFEAT (SACB) 
KSETFEAT (SCF) 
KSETFEAT (SCL) 


Display Queue Status (Feature DQS) Subtable 

Display Queue Threshold (Feature DQT) Subtable 

Distinctive Ringing (Feature DRING) Subtable 

Drop (Feature DROP) Subtable 

Executive Busy Override (Feature EBO) Subtable 

Extended Call Management (Feature ECM) Subtable 

Emergency Key (Feature EMK) Subtable 

Executive Message Waiting (Feature EMW) Subtable 

Forced Agent Availability (Feature FAA) Subtable 

Flexible Calling (Feature FC) Subtable 

Full Carrier Toll Deny for International Carriers (Feature FCTDINT) Subtable 
Fast Transfer (Feature FXR) Subtable 

Group Intercom All Call (Feature GIAC) Subtable 

Hands-Free Control (Feature HF, HFMUTE, MUTE, SOFTKEY) Subtable 


Intercom (Feature ICM) Subtable 

Inspect (Feature INSPECT) Subtable 

In-Session Activation (Feature ISA) Subtable 

Conference Join (Feature JOIN) Subtable 

Key Short Hunt (Feature KSH) Subtable 

Line Music on Hold (Feature LMOH) Subtable 

Line of Business Code (Feature LOB) Subtable 

Local (Feature LOCAL) Subtable 

Primary Intra-LATA Carrier (Feature LPIC) Subtable 

Local Service Provider Switch Owner (Feature LSPSO) Subtable 
Leave Message (Feature LVM) Subtable 

Meridian Business Set Camp-On (Feature MBSCAMP) Subtable 
Malicious Call Hold (Feature MCH) Subtable 

Malicious Call ID (Feature MCI) Subtable 

Medicated Individual Telephony (Feature MIPHONE) Subtable 
Multiple Appearance Directory Number Ring Forward Manual (Feature MRFM) 
Subtable 

Make Set Busy (Feature MSB) Subtable 

Message Waiting Indication (Feature MWIDC) Subtable 
Message Waiting Query (Feature MWORY) Subtable 
Message Waiting (Feature MWT) Subtable 

Number of DN Appearances (Feature NDNAP) Subtable 
Night Service (Feature NGTSRVCE) Subtable 

Network Resource Selector (Feature NRS) Subtable 
Observe Agent (Feature OBS) Subtable 

Originating Line Select (Feature OLS) Subtable 
Private Business Line (Feature PBL) Subtable 
Privacy Change Allowed Caller ID Delivery and Suppression 
Subtable 

Power Feature (Feature PF) Subtable 

Primary Inter-LATA Carrier (Feature PIC) Subtable 
Call Park (Feature PRK) Subtable 

Privacy Release (Feature PRL) Subtable 

Privacy (Feature PRV) Subtable 

Query Busy Station (Feature QBS) Subtable 

Quick Conference Key (Feature QCK) Subtable 

Query Time and Date (Feature QTD) Subtable 

Ring Again (Feature RAG) Subtable 

Random Make Busy (Feature RMB) Subtable 

Requested Suspension (Feature RSUS) Subtable 
Subscriber Activated Call Blocking (Feature SACB) Subtable 
Selective Call Forwarding (Feature SCF) Subtable 
Speed Calling Long List (Feature SCL) Subtable 


(Feature PCACIDS) 
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KSETFEAT (SCS) 
KSETFEAT (SDY) 
KSETFEAT (SEC) 
KSETFEAT (SHU) 
KSETFEAT (SIMRING) 
KSETFEAT (SLQ) 
KSETFEAT (SLU) 
KSETFEAT (SMDI) 
KSETFEAT (SOR) 
KSETFEAT (SPB) 
KSETFEAT (SSAC) 
KSETFEAT (SUPR) 
KSETFEAT (TBO) 
KSETFEAT (TLS) 
KSETFEAT (TRANSFER) 
KSETFEAT (TRKDISP) 
KSETFEAT (UCDLG) 
KSETFEAT (UCDSD) 


KSETFEAT (VMEADENY) 
KSETFEAT (VMEADN) 
KSETFEAT (WML) 
KSETFEAT (WUCR) 
KSETFEAT (XFER) 
KSETFEAT (XXTRG) 
KSETINV 
KSETKEYS 
KSETLINE 
KSETQCK 
KTGROUP 
KTMINMAX 
KTPARMS 
L2ABNLOG 
L3ABNLOG 

LAC 

LAMABC 

LANGTOQ 
LATANAME 
LATAXLA 
LATTRDR 
LCA6SCRN 
LCAINFO 
LCARNAME 
LCARSCRN 
LCASCRCN 
LCASCRCN.LCASCR 
LCCOPT 

LCLRS 

LCLRSI 
LCMDRINV 
LCMINV 

LDASCRN 

LDTINV 

LENFEAT 

LENFEAT (ADL) 
LENFEAT (AIN) 
LENFEAT (AIOD) 
LENFEAT (AUL) 
LENFEAT (BCLID) 


Speed Calling Short List (Feature SCS) Subtable 

AT&T line Study (Feature SDY) Subtable 

Security Code (Feature SEC) Subtable 

Stop Hunt (Feature SHU) Subtable 

Simultaneous Ringing (Feature SIMRING) Subtable 

Single Line Queue (Feature SLQ) Subtable 

Subscribers Line Usage (Feature SLU) Subtable 

Station Message Desk Interface (Feature SMDI) Subtable 
Station Origination Restrictions (Feature SOR) Subtable 
Special Billing Code (Feature SPB) Subtable 

Station Specific Authcode (Feature SSAC) Subtable 
Supervisor (Feature SUPR) Subtable 

Terminating Billing Option (Feature TBO) Subtable 
Terminating Line Select (Feature TLS) Subtable 

Call Transfer ISDN (Feature TRANSFER) Subtable 

Trunk Member Display (Feature TRKDISP) Subtable 
Uniform Call Distribution Login (Feature UCDLG) Subtable 
Uniform Call Distribution Signal Distribution Point (Feature UCDSD) 
Subtable 

Voice Mail Easy Access Deny (Feature VMEADENY) Subtable 
Voice Mail Easy Access Directory Number (Feature VMEADN) Subtable 
Warm Line (Feature WML) Subtable 

Wake-Up Call (Feature WUCR) Subtable 

Call Transfer ISDN (Feature XFER) Subtable 

XX Trigger (Feature XXTRG) Subtable 

Business Set and Data Unit Inventory Table 

Business Set Feature Keys Table 

Business Set and Data Unit Line Assignment Table 
Business Set and Data Unit Quick Conference Key Table 
Killer Trunk Group Table 

Killer Trunk Minimum Maximum Table 

Killer Trunk Parameters Table 

Layer-2 Abnormality Log Table 

Layer-3 Abnormality Log Table 

Location Area Code Table 

Local Automatic Message Accounting Billing Code Table 
Language-to-TOPS Call Queue Routing Table 

Equal Access Local Access and Transport Area Name Table 
Equal Access Local Access and Transport Area Translation Table 
LINEATTR Dump and Restore Table 

Local Calling Area 6 Screen Table 

Local Calling Area Information Table 

Local Calling Area Name Table 

Local Calling Area Screening Table 

Local Calling Area Screening Control Table 

Local Calling Area Screening Subtable 

Line Class Code Compatible Options Table 

TOPS Calling Tariff to Local Rate Step Table 

TOPS Calling Tariff to Local Rate Step Inactive Table 
Line Concentration Module Drawer Inventory Table 

Line Concentrating Module Inventory Table 

Long Distance Alerting Screening Table (MMP only) 

Line Appearance on a Digital Trunk Inventory Table 

Line Feature Table 

Abbreviated Dialing (Feature ADL) Subtable 

Advanced Intelligent Network (Feature AIN) Subtable 
Auto-Identified Outward Dialing (Feature AIOD) Subtable 
Automatic Line (Feature AUL) Subtable 

Bulk Calling Line Identification (Feature BCLID) Subtable 
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LENFEAT (CDA) 
LENFEAT (CFFPOVR) 
LENFEAT (CLI) 
LENFEAT (CSDDS) 
LENFEAT (CTD) 
LENFEAT (ESG) 
LENFEAT (ESL) 
LENFEAT (EWAL) 
LENFEAT (FCTDINT) 
LENFEAT (FRO) 
LENFEAT (FRS) 
LENFEAT (HTL) 
LENFEAT (IDND) 
LENFEAT (ILR) 
LENFEAT (INDC) 
LENFEAT (LPIC) 
LENFEAT (LSPSO) 
LENFEAT (MBK) 
LENFEAT (MPB) 
LENFEAT (OUTWT) 
LENFEAT (PIC) 
LENFEAT (RMB) 
LENFEAT (RMP) 
LENFEAT (RMS) 
LENFEAT (RSUS) 
LENFEAT (SC1) 
LENFEAT (SC2) 
LENFEAT (SCMP) 
LENFEAT (SDN) 
LENFEAT (SDY) 
LENFEAT (SHU) 
LENFEAT (SLU) 
LENFEAT (SPB) 
LENFEAT (TBO) 
LENFEAT (WLN) 
LENLINES 
LGINCTRL 
LIMCDINV 
LIMINV 
LIMPTINV 
LINEATTR 
LIUINV 
LKIDTAB 

LMINV 
LMOVCODE 
LMRNG 

LNADMIN 

LNBNV 

LNCODE 
LNETWORK 
LNINV 
LNINVEXT 
LNMPEOC 
LNMTRNAM 
LNPCODE 
LNPOPTS 
LNPRTE 
LNSIGSYS 
LNSIGSYS (DELDIAL) 


Call Diversion (Feature CDA) Subtable 

Call Forward Fraud Prevention Override (Feature CFFPOVR) Subtable 
Calling Line Identification (Feature CLI) Subtable 

Circuit Switched Digital Data Service (Feature CSDDS) Subtable 
Carrier Toll Denied (Feature CTD) Subtable 

Emergency Service Group (Feature ESG) Subtable 

Emergency Service with Ringdown Trunk (Feature ESL) Subtable 
Enhanced WATS Access Line (Feature EWAL) Subtable 

Full Carrier Toll Deny for International Carriers (Feature FCTDINT) Subtable 
Sleeve Lead Control (Feature FRO) Subtable 

Sleeve Lead for Public Fire Reporting System (Feature FRS) Subtable 
Hot Line (Feature HTL) Subtable 

International Do Not Disturb (Feature IDND) Subtable 
International Line Restrictions (Feature ILR) Subtable 
International No Double Connect (Feature INDC) Subtable 
Local Primary Intra-LATA Carrier (Feature LPIC) Subtable 
Local Service Provider Switch Owner (Feature LSPSO) Subtable 
Make Busy Key (Feature MBK) Subtable 

Multi-Party Bridge (Feature MPB) Subtable 

OUTWATS (Feature OUTWT) Subtable 

Primary Inter-LATA Carrier (Feature PIC) Subtable 

Random Make Busy (Feature RMB) Subtable 

Remote Meter Pulsing (Feature RMP) Subtable 

Remote Register Signal Distributor Point (Feature RMS) Subtable 
Requested Suspension (Feature RSUS) Subtable 

Speed Calling Short List (Feature SC1) Subtable 

Speed Calling Long List (Feature SC2) Subtable 

Series Completion (Feature SCMP) Subtable 

Secondary Directory Number (Feature SDN) Subtable 

AT&T Line Studies (Feature SDY) Subtable 

Stop Hunt (Feature SHU) Subtable 

Subscribers Line Usage (Feature SLU) Subtable 

Special Billing Code (Feature SPB) Subtable 

Terminating Billing Option (Feature TBO) Subtable 

Warm Line (Feature WLN) Subtable 

Line Assignment Table 

Login Control Table 

Link Interface Module Card Inventory Table 

Link Interface Module Inventory Table 

Link Interface Module Port Inventory Table 

Line Attribute Table 

Link Interface Unit Inventory Table 

Link Identifier Table 

Line Module Inventory Table 

Line-to-Trunk Overlap Outpulse Table 

Line Module Ring Code Table 

Line Administration Table 

Line Balance Network Value Table 

TOPS Line Number Method of Coin Control Table 

Logical Metering Networks Table 

Line Circuit Inventory Table 

Line Inventory Extension Table 

Line Multipoint Embedded Operations Channel Table 

Line Meter Names Table 

Local Number Portability Code Table 

Local Number Portability Options Table 

Local Number Portability Route Table 

Line Signaling System Table 

Signaling Type DELDIAL Subtable 
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LNSIGSYS (N5) 
LNSIGSYS (NTLSO3) 
LNSIGSYS (NTLSO4) 
LNSIGSYS (NTLSO5) 
LNSIGSYS (NTLSO6 
Incoming) 
LNSIGSYS (NTLSO6 
Outgoing) 
LNSIGSYS (NTLSO7 
Incoming) 
LNSIGSYS (NTLSO7 
Outgoing) 
LNSIGSYS (NTLSO8 
Incoming) 
LNSIGSYS (NTLSO8 
Outgoing) 
LNSIGSYS (NTLSO9 
Incoming) 
LNSIGSYS (NTLSO9 
Outgoing) 
LNSIGSYS (NTLS10) 
LNSIGSYS (NTLS11 
Incoming) 
LNSIGSYS (NTLS11 
Outging) 
LNSIGSYS (NTLS14) 
LNSIGSYS (NTLS15 
Incoming) 
LNSIGSYS (NTLS15 
Outgoing) 
LNSIGSYS (NTLS16 
Incoming) 
LNSIGSYS (NTLS16 
Outgoing) 
LNSIGSYS (NTLS16 
Two-Way) 
LNSIGSYS (NTLS20 
Incoming) 
LNSIGSYS (NTLS20 
Outgoing) 
LNSIGSYS (NTLS22 
Incoming) 
LNSIGSYS (NTLS22 
Outgoing) 
LNSIGSYS (NTLS24 
Incoming/Outgoing) 
LNSIGSYS (WINKSIG) 
LNSMTCE 

LNTDM 

LNTHRSH 
LOGCLASS 

LOGDEV 

LOGINFO 

LPBKMEM 
LSCFLAGS 
LSPINFO 

LTCALLS 

LTCINV 

LTCPSINV 


Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 


Signaling 


Signaling 
Signaling 


Signaling 


Signaling 
Signaling 


Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 
Signaling 


Signaling 


Line Maintenance Table 


Type N5 Subtable 


Type NTLSO3 
Type NTLSO4 
Type NTLSO5 
Type NTLSO6 
Type NTLSO6 
Type NTLSO7 
Type NTLSO7 
Type NTLSO8 
Type NTLSO8 
Type NTLSO9 


Type NTLSO9 


Type NTLS10 
Type NTLS11 


Type NTLS11 


Type NTLS14 
Type NTLS15 


Type NTLS15 
Type NTLS16 
Type NTLS16 
Type NTLS16 
Type NTLS20 
Type NTLS20 
Type NTLS22 
Type NTLS22 


Type NTLs24 


Subtable 

Subtable 

Subtable 

Incoming Subtable 
Outgoing Subtable 
Incoming Subtable 
Outgoing Subtable 
Incoming Subtable 
Outgoing Subtable 
Incoming Subtable 


Outgoing Subtable 


Subtable 
Incoming Subtable 


Outgoing Subtable 


Subtable 
Incoming Subtable 


Outgoing Subtable 
Incoming Subtable 
Outgoing Subtable 
Two-Way Subtable 
Incoming Subtable 
Outgoing Subtable 
Incoming Subtable 


Outgoing Subtable 


Incoming/Outgoing Subtable 


Type WINKSIG Subtable 


Line Time Division Multiplex Table 
Lines and Thresholds Management Table 


Log Class 


Table 


Log Device Table 
Log Control Information Table 
Loopback Trunk Member Table 

Line Screening Code Flag Table 


Local Service Provider Information Table 


Logical Terminal Calls Table 
Line Trunk Controller Inventory Table 


Line Trunk Controller P-Side Link Inventory Table 
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LTCRINV 
LTCRPINV 
LTDATA 
LTDEF 
LTDSD 
LTGRP 
LTMAP 
LTPAUX 
LTPDEF 
MCCSNBEC 
MCCSOST 
MDESTIDX 
MDNGRP 
MDNMEM 
MDSACTN 
MDSLANG 
MDSOPT 
MFCACT 
MFCPROT 
MFCTRTMT 
MILES 
MILESI 
MINCHG 
MINCHGI 
MLCCOPT 
MMAO0-9 
MMCONF 
MNETATTR 
MOBCENT 
MODEMPRO 
MODMAP 
MODSET 
MOPTOPT 
MPBINV 
MPC 
MPCFASTA 
MPCLINK 
MPCLOGIN 
MPCLSET 
MPHCON 
MPHGRP 
MOLIMITS 
MRSANAME 
MSBINV 
MSBPSINV 
MSCDINV 
MSRCDATA 
MSFWLOAD 
MSGRTE 
MSILINV 
MSINV 
MTAHORIZ 
MTAMDRVE 
MTARF IDX 
MTARENUM 
MTARIFF 
MTAVERT 
MTCFAIL 
MTCTEST 


Line Trunk Controller Remote Inventory Table 

Line Trunk Controller Remote P-Side Link Inventory Table 
Logical Terminal Data Table 

Logical Terminal Definition Table 

Line Test Desk Signal Distribution Table 

Logical Terminal Group Table 

Logical Terminal Mapping Table 

Line Test Position Auxiliary Commands Table 

Line Test Position Default Commands Table 

Mechanized Calling Card Service Non-Bell Exchange Carrier Table 
TOPS Mechanized Calling Card Service Originating Station Treatment Table 
Metering Destination Index Table 

Multiple Appearance Directory Number Group Table 
Multiple Appearance Directory Number Member Table 

TOPS Message Delivery System Actions Table 

TOPS Message Delivery System Language Table 

TOPS Message Delivery Service Options Table 
Multi-Frequency Compelled Signal to Activity Translation Table 
Multi-Frequency Compelled Protocol Tuples List Table 

MFC Activity to Extended Treatment Translation Table 
TOPS Mileage Table 

TOPS Mileage Inactive Table 

TOPS Minimum Charge Table 

TOPS Minimum Charge Inactive Table 

Mobile Line Class Code Compatible Table 

Minimum, Maximum Digits, and Ambiguous Code Table 

IBN Meet-Me Conference Table 

Metering Network Attributes Table 

Mobile Centrex Provisioning Table 

Modem Protocol Name Definition Table 

ITOPS Rating Charge Calculator Day Charge Modification Map Table 
ITOPS Rating Charge Calculator Time Charge Modification Set Table 
Mobile Incompatible Options Table 

Multi-Party Bridge Inventory Table 

Multi-Protocol Controller Table 

Multi-Protocol Controller Fast Applications Table 
Multi-Protocol Controller Link Table 

Multi-Protocol Controller Login Table 

Multi-Protocol Controller Linkset Table 

Multiple Position Hunt Console Table 

Multiple Position Hunt Group Table 

Maintenance Q-Limits Table 

List of Multi-Unit Message Rate Area Names Table 
Message Switching Buffer Inventory Table 

Message Switching Buffer P-Side Inventory Table 

Message Switch Cards Inventory Table 

Metering Source Data Table 

Message Switch Firmware Load Table 

PRA Facility Message Routing Table 

Message Switch Inter-MS Link Inventory Table 

Message Switch Inventory Table 

Metallic Test Access Horizontal Connection Table 
Metallic Test Access Minibar Driver Table 

Metering Tariff Index Table 

Metering Tariff Number Table 

Metering Tariff Table 

Metallic Test Access Vertical Connection Table 
Maintenance Failure Messages Table 

Maintenance Failure Messages Table 
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Short Name Title 

MTD Magnetic Tape Device Table 

MTSIGSYS Hardware Metering for Trunks Signaling System Table 
MTRLNET Metering Logical Networks Table (MMP only) 

MTRLMOG Metered Originator Groups Table (MMP only) 

MTRMOTS Metered Originator Tariff Sets Table (MMP only) 
MTRNAMES Meter Names Table (MMP only) 

MTRNETIF Metering Network Dependent Information Table (MMP only) 
MTRSYSPM Metering System Parameters Table (MMP only) 
MTRTARIF Metering Tariffs Table (MMP only) 

MTRTTS Metering Time-and-Date Tariff Sets Table (MMP only) 
MUMRMBI Multi-Unit Message Rate Message Billing Index Table 
MUMRTAB Multi-Unit Message Rate Screening Table 

MWDATA Milliwatt Data Table 

N7CLLDGT N7 (CCITT No. 7) Called Global Title Table 
N7CLLGGT N7 (CCITT No. 7) Calling Global Title Table 
NACDGRP Network Automatic Call Distribution Group Table 
NARDATA Network Access Registers Data Table 

NATDGTAN National Digit Analyser Table 

NBECCODE Non-Bell Exchange Company Code Table 

NCOS Network Class-of-Service Table 

NCSADDR Network Control System Address Table 

NCSAPPL Network Control System Application Table 

NETATTR Network Attributes Table 

NETJUNCT Network Junction Group Table 

NETNAMES Internal Logical Network Names Table 

NETTOPRT NETINFO-to-Partition Number Mapping Table 

NETTOSTS Network Information Table 

NETWORK Network Assignment Table 

NIUINV Network Interface Unit Inventory Table 

NLUPCLLI Nailed-Up Connection CLLI Table 

NMSDATA Network Message Service Data Table 

NNASST Node Number Assignment Table 

NO6BDXLA CCITT No. 6 Band Translation Table 

NO6LINKS CCITT No. 6 Signaling Links Table 

NO6LKSET CCITT No. 6 Link Set Table 

NO6RTSET CCITT No. 6 Route Set Table 

NO6STP CCITT No. 6 Signal Transfer Point Table 

NO6STPBD CCITT No. 6 Signal Transfer Point Table 

NO6TKMEM CCITT No. 6 Trunk Member Table 

NOPADDR Network Operations Protocol Address Table 

NOPAPPLN Network Operations Protocol Applications Table 
NOPDEST Network Operations Protocol Destination Table 
NOPUSERS Network Operations Protocol Users Table 

NPACAT Serving NPA Category Digit Table 

NPACHECK TOPS NPA Check Table 

NPASPLIT Numbering Plan Area Split Management Table 

NPDIGMAP Number Portability Digit Mapping Table 

NPENDING Number Pending Table 

NPRESERV Number Pooling Reserved Number Marketing Table 
NSCANNS Number Service Code Announcement Table 

NSCCARR Number Service Code 800 Plus Southbound Carrier ID Validation Table 
NSCCODE Number Service Code Table 

NSCDEFS Number Service Code Database Response Timeouts Table 
NSCHEAD Number Service Code Head Table 

NSCRTE Number Service Code Route Table 

NSCSCRN Number Service Code Screening Table 

NSCSNPA Number Service Code Special Area Codes Table 

NS IMAP Non-Specified Information String Map Table (MMP only) 
NSTAFAS Night Service Trunk Answer From Any Station Table 
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Short Name Title 

NTCLANGS Notification of Time and Charge Languages Table 

NUMBFMT ITOPS Position Display Number Formatting Table 

NUMDIGS Number of Digits Table (MMP only) 

NWMAOCR Network Management Automatic Out-of-Chain Reroute Table 

NWMCLLI Network Management CLLI Table 

NWMIDOC Network Management Internal Dynamic Overload Control Table 

NWMPPLN Network Management Pre-Plan Control Table 

NWMSC Network Management Scan Group Table 

NWMSCPT Network Management Scan Point Table 

NWMSD Network Management Signal Distributor Group Table 

NWMSDPT Network Management Signal Distributor Point Table 

NX64MEM NX64 Member Table 

OACAUPRF Operator Services Systems Advanced Intelligent Network (OSSAIN) 
Cause Profile Table 

OACNNPRFE OSSAIN Connecting Profile Table 

OACTLDEF Control List Definition Table 

OADSCPRF OSSAIN Post Disconnect Profile Table 

OADTFPRE OSSAIN Dual-Tone Multi-Frequency Profile Table 

OAFUNBLK OSSAIN Function Blocking Table 

OAFUNDEF OSSAIN Function Definition Table 

OAFNDISP OSSAIN Function Disposition Table 

OAINCTLA OSSAIN Control List Assignment Table 

OAINPARM OSSAIN Parameters Table 

OAINPRE OSSAIN Pre-Processing Table 

OAINRTE OSSAIN Route Table 

OANODINV OSSAIN Node Inventory Table 

OANODNAM OSSAIN Node Name Table 

OATLKPRE OSSAIN Talking Profile Table 

OATPRFIX OSSAIN Trigger Profile Table 

OASESNPL OSSAIN Session Pool Table 

OAVLMAP OSSAIN Node Inventory Table 

OCCINFO Equal Access Other Common Carrier Information Table 

OCCMAP Equal Access List of Other Common Carrier Mapping Table 

OCCNAME Equal Access List of Other Common Carrier Names Table 

OCCRDIG Equal Access Other Common Carrier R-Digit Table 

OCCSRV Equal Access Other Common Carrier Service Data Table 

OCCTSINT Equal Access Other Common Carrier Traffic Separation Intersection Table 

OCDLGRP Operator Centralization Data Link Group Table 

OCGRP Operator Centralization Group Table 

OCHOST Operator Centralization Host Table 

OCHOSTQ Operator Centralization Host Queue Table 

OCIPDL Operator Centralization Internet Protocol Map Table 

OCOF'C Operator Centralization Office Table 

OCPARMS Operator Centralization Parameter Table 

OFC Outbound Facility Table 

OFCAUT Office Auto-Provisioning Table 

OFCCODE Office Code Table 

OFCHEAD Office Code Head Table 

OFCRTE Office Code Route Table 

OFRT Office Route Table 

OFRT (AFR) Automatic Flexible Routing (Selector AFR) Subtable 

OFRT (CND) Calling Number Delivery (Selector CND) Subtable 

OFRT (DCRT) Dynamically Controlled Routing (Selector DCRT) Subtable 

OFRT (DN) Directory Number (Selector DN) Subtable 

OFRT (ISA) Integrated Service Access (Selector ISA) Subtable 

OFRT (MEM) Trunk Group Member (Selector MEM) Subtable 

OFRT (MN) Route Selector MN (Selector MN) Subtable 

OFRT (N) Route Selector N (Selector N) Subtable 

OFRT (N2) Route Selector N2 (Selector N2) Subtable 
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Short Name Title 

OFRT (NODE) Route Selector NODE (Selector NODE) Subtable 
OFRT (NOT) Route Selector NOT (Selector NOT) Subtable 
OFRT (NPOS) Route Selector NPOS (Selector NPOS) Subtable 
OFRT (NPOSDN) Route Selector NPOS (Selector NPOSDN) Subtable 
OFRT (QH) Queue Head (Selector QH) Subtable 

OFRT (RT) Retranslate (Selector RT) Subtable 


OFRT (RX) Retranslate IBN (Selector RX) Subtable 
OFRT (S) Route Selector S (Selector S) Subtable 
OFRT (SG) Super Trunk Group (Selector SG) Subtable 
OFRT (ST) Same Subtable (Selector ST) Subtable 

OFRT (SX) Route Selector S (Selector SX) Subtable 
OFRT (T) Route Selector T (Selector T) Subtable 
OFRT (TC) Route Selector T (Selector TC) Subtable 
OFRT (TPBX) Route Selector TPBX (Selector TPBX) Subtable 
OFRT (TRMT) Treatment (Selector TRMT) Subtable 

OFRT (TS) Two-Stage (Selector TS) Subtable 

OFRT (UOP) Uniform Outpulsing (Selector UOP) Subtable 
OFR2 Office Route-2 Table 

OFR3 Office Route-3 Table 

OFR4 Office Route-4 Table 

OFCTIID Office Trigger Item identifier Table 
OFRTMAP ISDN OFRT Route Reference Table 

OFRTMA2 ISDN OFR2 Route Reference Table 

OFRTMA3 ISDN OFR3 Route Reference Table 

OFRTMA4 ISDN OFR4 Route Reference Table 

OGTMPKEY Outgoing Trunk Multi-Purpose Key Table 
OGTSPKEY Outgoing Trunk Single-Purpose Key Table 
OHBTADMN Off-Hook Balance Testing Administration Table 
OHBTINV Off-Hook Balance Testing Inventory Table 


OHIP Office Hardware Inventory Package Table 


OHIPBULK Bulk Hardware Inventory Package Table 

OIASTART Open Information Access Automatic Session Start Table 
OICBC Office Identification Code Billing Code Table 
OLNSDARS OLNS Directory Assistance Billing Restriction Table 
OLNSDFLT OLNS Default Table 

OLNSEQDP OLNS Service/Equipment Display Table 

OLNSERR OLNS Error Table 

OLNSLANG OLNS Language Table 

OLNSRSDP OLNS Originating Line Number Screening Restricted Billing Display Table 
OLNSTARS OLNS Toll and Assist Billing Restriction Table 
OMACC Operational Measurements Accumulator Table 

OMACCESS Operational Measurements Group Access Table 
OMACCFLD Operational Measurements Accumulator Field Table 
OMACCGRP Operational Measurements Accumulator Groups Table 
OMACCKEY Operational Measurements Accumulator Key Table 
OMACCTOT Operational Measurements Accumulator Total Table 
OMDEV Operational Measurements Device Table 

OMGRPORD Operational Measurements Group Order Table 

OMPRT Operational Measurements Printer Table 

OMREPORT Operational Measurements Report Table 

OMTAPE Operational Measurements Output Recording Table 
OMTHRESH Threshold Alarms Table 

OMTOTAL Operational Measurements Totaling Table 

OOCBILL 0OC Overseas Billing Restrictions Table 

OPENANT Open Numbering Plan ANI Table 

OPMINV Outside Plant Module Inventory Table 

OPRCMPLX Table Operator Complex and Unit ID Table 

OPRDAT TOPS Operator Data Table 

OPRINFO Operator Information Table 
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Short Name Title 

OPRPRFX ITOPS Operator Automatic Prefixing Table 

OPRTRANS TOPS Operator Translations Table 

OPTCTL Option Control Table 

OPTOPT Incompatible Options Table 

OPTTREAT Optional Treatment Table 

OQCQPROF OSSAIN QMS Call Queue Profile Table 

ORIGRC TOPS Point-to-Point Rating Originating Rate Centers Table 
OSCVLGRP OSSAIN Centralization Voice Link Group Table 
OSIPARMS Open Systems Interconnect Parameter Table 
OSIROUTE Open Systems Interconnect Routing Table 

OSNCCAP Operator Services Network Capability Table 
OSSANNS Operator Services System Announcements Table 
OSSCAT ANIID Mapping for TOPS Trunk Groups with OSS Table 
OSSPROV Operation System Support Provisioning Table 
OVNTRNSL Overseas Number Translation Table 

OVRO-9 Overseas Route Tables 

OVRMAP Overseas Route Index Mapping Table 

OVSBILL TOPS Overseas Billing Restrictions Table 

Ovscc TOPS Overseas Credit Card Table 

OvsccYyL TOPS Overseas Credit Card Year Letter Table 

OVSRS TOPS Overseas Rate Step Table 

OVSRSI TOPS Overseas Rate Step Inactive Table 

OWAT ZONE OUTWATS Zone Table 

OWNER Owner Table 

OWNTAB Ownership Table 

PACMAN IBN ESN Protocol Analysis and Code Manipulation Table 
PADDATA Pad Data Table 

PADNDEV Patch Administration Device Table 

PARSDENY TOPS Personal Audio Response System Denial Table 
PARSMBR TOPS Personal Audio Response System Member Table 
PATALARM Patch Alarm Table 

PATCHOPT Patcher Options Table 

PATCTRL Patch Control Table 

PATNS Patch Nodeset Table 

PATSET Patch Set Table 

PCIC Phantom Carrier Identification Code Table 

PCITRK Preselect Carrier Identification Trunk Table (MMP only) 
PCIXLA Preselect Carrier Identification Translation Table (MMP only) 
PECINV Product Engineering Code Inventory Table 

PFCTRL Power Feature Control Table 

PFXTREAT Prefix Treatment Table 

PHDS1 Packet Handler to DS-1 Connection Table 

PHINFO Packet Handler Information Table 

PHINV Packet Handler Inventory Table 

PICNAME Primary Inter-LATA Carrier Name Table 

PILOTGRP Pilot Groups Table 

PINDATA Personal Identification Number Data Table 

PLATAB Physical Link Adapter Table 

PMEXCEPT Peripheral Modules Excepted Table 

PMLOADS Peripheral Module Loads Table 

PMNODES Peripheral Module Nodes Table 

PNINFO Ported Number Routing Information Table (MMP only) 
PNSCRN Ported Number Screening Table (MMP only) 

PODPATTR Public Office Dialing Plan Attributes Table 
POECNM Path-of-Entry Characteristic Name Table 

POECSCRN Path-of-Entry Characteristic Screening Table 
PORTNUMS Portable Numbers Table 

POSITION Position Table 

POSNAME List of Position Names Table 
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Short Name Title 

PRECONF Preset Conference Table 

PREFHUNT Preferential Hunt List Member Table 

PREPLANS Network Management Preplan Table 

PRIPROF Primary Rate Interface Profile Table 

PRTN2CCD Pre-Translator to CC Translator Name Table 

PRTTONET Partition Number to NETINFO Mapping Table 

PS Program Store Assignment Table 

PSCNUM Private Speed Call Number Table 

PSNAILUP P-Side Nail-Up Table 

PSTNTRK Public Switched Telephone Network Trunk Table 

PTIDTAB Port Identifier Table 

PTP TOPS Point-to-Point Rating Table 

PVCINFO Permanent Virtual Circuit Information Table 

PVCTYPE Permanent Virtual Circuit Type Table 

PVDNAGEN Private Virtual Data Network Agent Table 

PVDNCHAN Private Virtual Data Network Channel Table 

PVDNCUST Private Virtual Data Network Customer Table 

PVDNCUST. AGENTS Private Virtual Data Network Customer Agents Subtable 
PVDNCUST. CONNECT Private Virtual Data Network Customer Connect Subtable 
PXCODE Prefix Code Table 

PXHEAD Prefix Code Head Table 

PXLAMAP ISDN Pre-Translation Map Table 

PXRTE Prefix Code Route Table 

QAPLNDEF Queue Management System Application Definition Table 
QCLASS ITOPS Automatic Call Distribution Call Classes Table 
QDEF ITOPS Automatic Call Distribution Call Queues Table 
QMSCQDEF Queue Management System Call Queue Definition Table 
QMSMIS Queue Management System MIS Link Definition Table 
QMSTOPS Queue Management System TOPS Initial Call Type Assignment Table 
QPROFILE ITOPS Automatic Call Distribution Operator Call Handling Table 
QPROP ITOPS Automatic Call Distribution Call Properties Table 
QTO-QT5D ooc Day Queue Length Threshold Table 

QTO-QT5H ITOPS Queue Length Threshold High-Traffic Table 

QTO-QT5L ITOPS Queue Length Threshold Low-Traffic Table 

QTO-QT5N ooc Night Queue Length Threshold Table 

QOTHRESH ITOPS Queue Threshold Limits Table 

QTTIDXD ooc Day Queue Length Threshold Table Index Table 

QTTIDXH ITOPS Queue Length Threshold High-Traffic Table Index Table 
QTTIDXL ITOPS Queue Length Threshold Low-Traffic Table Index Table 
QTTIDXN ooc Night Queue Length Threshold Table Index Table 
R2BILSRV R2 Billing Service Table 

R2CLGSRV ITOPS Mapping R2 Trunk Signal-to-Table ITOPSERV Index Table 
R2PROT R2 Protocol Description Table 

RADR Receiver Attachment Delay Recorder Table 

RAINV Resource Aggregate Inventory Table 

RALNK Resource Aggregate Link Table 

RAO TOPS Domestic RAO Codes Table 

RAOCHECK TOPS RAO Check Table 

RASLAPPL Robust Application Session Layer Application Table 
RATEAREA Rate Area Table 

RATEMOD TOPS Rate Break Map Table 

RBKMAP TOPS Rate Break Map Inactive Table 

RBKMAPI TOPS Rate Break Set Table 

RBKSET TOPS Rate Break Set Inactive Table 

RBKSETI Remote Cluster Controller Inventory Table 

RCCINV Remote Cluster Controller P-Side Link Inventory Table 
RCCPSINV Remote Call Forwarding Calling Line Identification Table 
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X-Band Receive Converter 


This is a device which will allow a person to monitor the X— & Ku-band frequency ranges (8-14 
GHz) using conventional low-frequency receivers or RF test equipment. The converter works by 
mixing an incoming frequency with a clean, low-noise, phase-locked 10 GHz local oscillator 
signal. The Intermediate Frequency (IF) output of the RF mixer will then be in the DC to 3.0 GHz 
frequency range. 


Overview 


Constructing a phase-locked 10 GHz signal source will be the most difficult part of this 

project. There is a simple solution, though. Hittite Microwave Corp. makes a very nice chip (and 
matching evaluation board) called the "HMC444 x8 Active Frequency Multiplier." What this 
component does is multiple an incoming frequency between 1.2-1.5 GHz eight times for a new 
output frequency in the 9.6—-12 GHz range. So, by inputting a phase-locked RF signal at 1.25 GHz, 
you'll get a nice stable 10 GHz signal which can then power the local oscillator port on your RF 
mixer. 


The 1.25 GHz Phase—Locked Loop (PLL) oscillator for this project will be based around a slightly 
modified homebrew Amateur Television (ATV) transmitter for the 23 cm (1.2-—1.3 GHz) amateur 
radio band. The synthesizer for this converter will be the Motorola MC145151 PLL chip, which is 
easily salvageable from old commercial satellite/CATV receivers and even some older two—way 
VHF radios. The PLL will require an external "divide—by—128" prescaler to convert the 1.25 GHz 
output frequency down to something the MC145151 can handle. We'll be using a Fujitsu MB506 (or 
NEC UPB1507 or Motorola MC12022) prescaler, which can be found in some MMDS 
downconverters or in older Nokia/Uniden analog cellular phones and 900 MHz cordless phones. 


The VCO for the oscillator will be a Z-Comm CLV1137, which was designed to only cover the 
1,100—1,175 MHz range. It'll be operated "out-of-band" for this project as it was the only VCO 
module | had available which covered this frequency range. Mini—Circuits has many different VCO 
modules which should also work. Just look for something with a similar MHz/Volt rating and 
frequency range as the Z-Comm CLV1137 so you don't have to fiddle with the MC145151's loop 
filter calculations. 


An evaluation board for the HMC444 multiplier will be used here to help minimize the need for 
constructing PC boards operating in the 10 GHz range. The HMC444 evaluation board is ready to 
operate as it comes, just add +5 VDC. The HMC444 takes a RF input level of around —5 to 0 dBm, 
multiples the signal eight times, and outputs a new RF signal with an output power of around +6 
dBm. It does all this without any arcane supporting components! The HMC444 evaluation board is 
available for order directly from Hittite. 


This device is handy for monitoring any law enforcement RF signals at around 10.525 

GHz. X-band radar guns operate near this frequency and also some older analog video 
surveillance transmitters. Those video signals can be easily demodulated using standard FM video 
demodulation techniques — once you get it down to a lower frequency. You can also monitor those 
Ku-band (13-14 GHz) satellite uplink transmissions which operate near the various NFL 

stadiums. Certain cable TV companies also have unencrypted NTSC point-to-point microwave 
relay transmissions in the Ku-band for when they can't run coaxial cable. This is very handy if you 
don't want to pay for cable TV... 
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Pictures & Construction Notes 





Constructing the 1.25 GHz phase-locked loop oscillator board. 


The Z-Comm CLV1137 is the silver square on the lower-right. The 8—pin SMT chip next to it is the 
Fujitsu MB506 prescaler. The 8-pin DIP chip to the left of the CLV1137 is an EL2020 
wide—bandwidth op—amp. To the left of that, is a MC33171 low-power op—amp for the PLL loop 
filter. 


On the upper-right are the 78M05 and 78M12 voltage regulators. The 8—pin SMT chip to the left of 
the voltage regulators is an ICL7660 negative voltage regulator for powering the op—amps. 


The EL2020 op-—amp isn't really needed for this converter project, but it will allow you to modulate 


the VCO if you should ever require. A wide—bandwidth op—amp like the EL2020 also isn't 
necessary unless you plan to modulate the VCO with a video signal. 
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Overview of the Motorola MC145151 PLL circuitry. 

The passive components for the MC145151's loop filter are shown just below the MC145151. 
The 2N3904 transistor on the upper-left is for controlling a "PLL Lock" LED. 

For this converter project, the MC 145151 will be using an external 10 MHz 


Temperature-—Compensated Crystal Oscillator (TCXO) for generating the MC145151's reference 
frequency (78,125 Hz). 
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Overview of the completed 1.25 GHz phase-locked loop oscillator board. 


The blue multiturn potentiometer in the middle is for adjusting the deviation of any optional 
modulating signal. 


There are two feed-through capacitors (lower-right) for supplying clean +12V and +5V for the 
TCXO and HMC444 evaluation board. 


Note that the pictures and schematic of this oscillator board will vary due to constant tweaking. The 
schematic will have the correct component values. 
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Closeup view of the completed 1.25 GHz phase-locked loop oscillator board. 

Main +15V DC input to the board is via a feed—through capacitor (lower-—left). 

The RF output (upper-left) is via a N connector. 

The external 10 MHz signal for the MC145151 input (middle-left) is via a BNC connector. 
Modulation input (lower-—left) is via a F connector. 


The final RF output of this oscillator was —5 dBm. 
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Closeup view of the completed 1.25 GHz phase-locked loop oscillator board. 
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External 10 MHz TXCO crystal reference oscillator. 


It is a EG&G Frequency Products, Inc. model T424 and was from an old Qualcomm OmniTRACS 
satellite fleet tracking system. 


The TCXO just needs a source of +12V and a large bypass capacitor (83 uF or so). The output of 
the TCXO is via a short piece of coax with a BNC connector. 


Any 10 MHz crystal oscillator will do, but remember that any frequency error or noise in the PLL 
reference frequency will essentially be multiplied 128,000 times. 


It's also possible to tune this particular 10 MHz oscillator to within a few Hertz of 10 MHz by 
zero—beating its signal to WWV. 


EG&G TCXO Pinout 


27x 2” TCXO PINOUTS 
Oo Oo Oo 
RF +12V NC 


oO oO 
(BOTTOM VIEW) 





GND 
0 om 
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Attaching the external 10 MHz TXCO crystal to the outside of the MMDS downconverter case 
housing the oscillator board. 


The 10 MHz signal is applied to the oscillator board via the gold—colored BNC connection. 
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The microwave-range RF mixer for this converter is based around a salvaged Magnum MO64 
mixer. 


A short piece of conformable coax with a male SMA connector was added for the LO input to the 
MO64 mixer. This little module's original LO signal was disabled. 


The lower female SMA connector is the mixer's IF output. 
The upper female SMA connector is the mixer's RF input. 


The MO64's specifications are: 


RF Range: 6.0-12.5 GHz 
LO Range: 5.0-15.0 GHz 
IF Range: DC-2.5 GHz 
LO Power: +10 dBm 
Conversion Loss: 5.0 dB 


Any RF mixer with similar specifications will also work. Note that we'll be running the LO power 


below the required level, which can increase the mixer's conversion loss. The "RF" and "LO" ports 
can be interchanged on most mixer models with minimal performance loss. 
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Overview of the Hittite HMC444 evaluation board. 


The 1.25 GHz RF input will via the right-side SMA connector and the "multiplied—by—8" 10 GHz RF 
output will be via the left-side SMA connector. 


The SMA connector labeled "Vda" is for the HMC444's +5 VDC input. 
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AC power input for the ammo box case we'll be using. 


Filtered 120 VAC input goes through a circuit breaker and power switch. This is then applied to a 
18 VDC / 200 mA wall—-wart power supply which will be powering the oscillator and multiplier 
circuits. 
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Mounting the Magnum MO64 mixer and HMC444 evaluation board. 


+5 VDC power for the HMC444 active multiplier comes in via the SMA connector on the right-side 
of the board. 


The HMC 444 evaluation board has some double-sided foam tape on the bottom of the board to 
prevent it from flopping around. 
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Mounting the 1.25 GHz oscillator module to the side of the case. 
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Overview of the front-panel and 1.25 GHz oscillator to HMC444 board connections. 


A high-quality N connector will be used for the microwave RF input. 
A BNC connector is used for the IF output. 
A phono jack is used for the modulation input. 


A green LED indicates when the PLL is locked. 
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Finished case overview. 


The RF input is via the N connector, which has a protective shell from an old PL—259 connector. 
The downconverted IF output is via the BNC connector. 


Any (optional) modulation signal for the VCO will be via a phono jack mounted under the BNC 
connector. 


The green "PLL Lock" LED starts out dim when initially powered, but glows brighter when the PLL 
locks. A"PLL Unlock" LED might have been a better choice. 


To operate the converter, apply your X-band or Ku-band FF signal (trying not to exceed 0 dBm) to 


the RF mixer's input. It will then be mixed with the 10 GHz LO signal and your new lower frequency 
signal will be taken at the mixer's IF output. 
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13.0375 GHz Ku-band point-to-point relay link transmitter for a local TV station. 


Using this converter project you can monitor video transmissions, if you are in the link's 
beamwidth. The "downconverted" frequency would be 3.0375 GHz. Analog video links, which are 
getting to be rare, are often just standard NTSC while digital links can be in the standard MPEG-—4 
format. 


To view an analog (NTSC) transmission, you'd need to further downcovert the IF output frequency 
to something your TV can receive (100-900 MHz or so). To view a digital transmission, you'd need 
to apply the IF output frequency to the input of a C-band satellite receiver capable of decoding 
standard MPEG-4 format. You may need to further downconvert the signal if the receiver requires 
something between 950-1450 MHz. 


The more advanced student should note that this process also works in reverse. Say, should you 
ever need to broadcast a quick video or audio message to the audience of your local TV station. 
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A few years ago, brain-dead liberals and the pee—pee touchers at $2600 Magazine were frothing 
on—and-on about the NSA “illegally listening to every phone call" in the U.S. Never mind this isn't 
even technically possible but, hey, whatever gets you in the pants of 12-year-old boys. Anyway, 
back in the real world, it turns out the NSA was just grepping through Call Detail Record (CDR) 
data. This is basically phone switch data which logs a call desination, routing, length, etc. It does 
NOT record any audio of the actual call. Sure, the NSA doing this is shady, but it's hardly the end of 
the world. 


Well, look what | found in an unlocked dumpster! DMS switch DCR data! Feel free for anyone to 
use this fact to counter any stupid EFF lawsuits. 


FIRST COLUMN IS DMS-25@ CDR FIELD NUMBER 
REFER TO NTI 297~2621-119 TABLE 4-B 


24) **ORIGDATE 222 AUG 10 

@6) **ORIGTIME 19047 15:52:21 
@8) **DISCTIME 19057 15:52:51 
12) **CALLDUR 18 06:00:18 
16) **COLLTIME @ 00:00:00 


15) **DIALEDNO 8008925563 
17) **CALLEDNO 4142460900 
39) **BILLNUM 8008925563 
40) **ACCTCD NULL 

10) **ANISP 4045225673 


26) **TRTMTCD @ NO_TREATMENT 
@4) **ANSTYPE 4 HARDWARE ANSWER 
14) **COMPCODE @ NORMAL CALL 

31) **ORIGGRP 1241 MC7CHCGSPRD8 
32) **O EM 0236 

35) **T ah QP 54 MSEMILW611U0 
36) **TF OEM 0143 

29) ANISUFF 4 TRUE 1+ 

21) ADIN NULL NOT USED 

37)  COSOVE N 

@3)  CNPREDIG @ NO PFX 

@2)  DISCDATE 222 AUG 10 

33)  DIGDATA N NOT USED 

25)  FINSID 000 

38) FINTKGRP @ NOT SS7 CALL 
11)  INFODIG @ IDENTIFIED LINE 


20)  OPART @e1 
22)  ORIGOPRT 001 

@5)  PINOIGS NULL 

19) PREDIG @ NO PFX 
@7) QUEVED N 

@1)  RECCD FO 

18)  RTENO 1) 

28) RTELIST 0072 

23)  SEQNUM 03260 

30)  DISCTYPE @ 

@9)  TIMECHNG N 

27) TPART @1 

34) TRAP N 

13) UNIVACC NULL 
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End of Issue #74 





Any Questions? : 
Editorial and Rants 


More surveillance cameras for Eric Corley's New York City! Didn't John Brennan just 
say there were no Islamic terrorists out there? LOL! 


Bloomberg Wants ‘Big Brother Britain’ For NYC 
May 11, 2010 — From: www.wcbstv.com 
By Charlie D'agata 


Mayor Michael Bloomberg has his eye on more security against terror attacks. He went to London 
Tuesday to check out their surveillance camera system, one of the largest in the world. 


Ever since the Times Square car bomb scare on May 1, the mayor's been looking to build up New 
York's camera network. 


That means adding to the ring of steel in Times Square, similar to central London's. The mayor said 
more NYPD surveillance cameras may prevent another terror scare. 


London has 500,000 surveillance cameras, more than any other city in the world. 
Bloomberg visited London's mayor to see how these help Britain fight terror. 


"We live in a world of suicide bombers. We live in a world of international terrorism," Bloomberg 
said. 


And a world where both cities have been targets. Bloomberg came to take a closer look at the 
sprawling security network throughout London —- known as the "Ring of Steel." The mayor's 
hoping to beef up New York's own surveillance system in the wake of the failed car bomb attack in 
Times Square. 


"It's not clear that they would have helped in Times Square. Other than if the perpetrator knew 
there were cameras, he might not have tried to come into Times Square," Bloomberg said. 
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London's about the same size as New York and its transit systems handle roughly the same number 
of people every day. 


Nearly everywhere you look in London, there's someone or some "thing" looking right back at 
you. In fact, you could be caught on camera as many as 300 times in the course of one day. 


Cameras record the license plate of every single car that enters the capital. Yet it didn't stop 
terrorists from planting a car bomb outside this downtown nightclub three years ago. It failed to go 
off. 


"Nobody's going to make the world perfectly safe, but wouldn't you rather be somewhat safer?" 
Bloomberg said. 


He's banking on it as he plans to take "Big Brother Britain" back to New York City. 


London's "Ring of Steel" was the inspiration for the 3,000—camera network being installed in lower 
Manhattan and Midtown. The NYPD hopes all the cameras are installed by the end of 2011. 


We need to bail out 
more subprime homeowners 
from their debt 
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Eric Corley's New York City sure is ass—backwards! Your kid can't count? Don't 
worry! They'll work for Obama's census bureau or ACORN! 


N.Y. Passes Students Who Get Wrong Answers on Tests 


June 6, 2010 — From: www.nypost.com 
By Carl Campanile & Susan Edelman 
When does 2 + 2 = 5? 

When you're taking the state math test. 


Despite promises that the exams —- which determine whether students advance to the next 
grade —- would not be dumbed down this year, students got "partial credit" for wrong 
answers after failing to correctly add, subtract, multiply and divide. Some got credit for no 
answer at all. 


"They were giving credit for blatantly wrong things," said an outraged Brooklyn teacher who was 
among those hired to score the fourth-grade test. 


State education officials had vowed to "strengthen" and "increase the rigor" of both the questions 
and the scoring when about 1.2 million kids in grades 3 to 8 —— including 450,000 in New York City 
—- took English exams in April and math exams last month. 


But scoring guides obtained by The Post reveal that kids get half—credit or more for showing 
fragments of work related to the problem —- even if they screw up the calculations or leave the 
answer blank. 


Examples in the fourth-grade scoring guide include: 


e A kid who answers that a 2-foot-long skateboard is 48 inches long gets half—credit for adding 24 and 24 instead 
of the correct 12 plus 12. 


e A miscalculation that 28 divided by 14 equals 4 instead of 2 is "partially correct" if the student uses the right 
method to verify the wrong answer. 

¢ Setting up a division problem to find one-fifth of $400, but not solving the problem —- and leaving the answer 
blank —- gets half—credit. 


e A kid who subtracts 57 cents from three quarters for the right change and comes up with 15 cents instead of 18 
cents still gets half—credit. 


e A student who figures the numbers of books in 35 boxes of 10 gets half—credit despite messed—up multiplication 
that yields the wrong answer, 150 instead of 350. 


These questions ask students to show their work. The scoring guidelines, called “holistic rubrics," 
require that points be given if a kid's attempt at an answer reflects a "partial understanding" of the 
math concept, "addresses some element of the task correctly," or uses the "appropriate process" to 
arrive at a wrong solution. Despite flubbing the answer, students can get 1 point on a 2-point 
problem and 1 or 2 points on a 3-pointer. 


The Brooklyn teacher said she and peers who had trained to score the tests were stunned at some 
instructions. 


"Everybody in the room was upset," she said. 
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The teacher had scored tests with some "controversial questions" for several years, but "this time it 
was more outrageous," she said. "You feel like you're being forced to cheat." 


Scorers joked about giving points to kids who wrote their names, brought a pencil or shared gum. 
However, score inflation is not funny, the whistleblower said. 


"The kids who really need the help are just being shuffled along to the next grade without the 
basic skills to have true success. They are given a hollow success —- that's the crime of 
it. The state DOE is doing a disservice to its children." 


Some testing experts are also troubled. 


Ray Domanico, a former head of data analysis for city schools, said kids deserve a little credit for 
partial knowledge but agreed the scoring system "raises some questions about whether it's to 
generous." 


State Education Department spokesman Tom Dunn defended the scoring. 


"All teachers who score exams receive clear training and rubrics that detail scoring criteria for every 
question on the tests," he said. "Students who show work and demonstrate a partial understanding 
of the mathematical concepts or procedures embodied in the question receive partial credit." 


But a few extra points can let a failing kid squeak by. 


A year ago, Chancellor Joel Klein boasted that the city was making "dramatic progress" when 82 
percent of city students passed the state math test and 69 percent passed in English, up sharply 
from 2002. And fewer kids have been left back in recent years. 


What officials didn't reveal was that the number of points needed to pass proficiency levels has, in 
most cases, steadily dropped. 


The state Board of Regents, which oversees the tests, has postponed the release of results until 
late July, but let the city Department of Education set its own "promotional cut scores" to decide 
which kids may be held back. The DOE will release those scores in the next two weeks, a 
spokesman said. 
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MUSLIMS 


Three o'clock, time to pray, no matter what. 





LOL! Soccer! 
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Ohh... Look! 
Muslim terrorist goatfuckers in the U.K are using wireless microphones during their little rallies. 


| sure hope nobody finds that particular frequency and transmits any rude messages or squealing 
pig noises on it! That would be very bad and not "culturally" sensitive! 


] Had enough ii" a 
HOPE an « 


CHANGE?’ 


Freedom Across com 
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For just 75 cents a day, you too can sponsor this malnourished Kenyan Muslim! 


Think about it. For only the price of a cup of coffee, you can clean him up, educate him, and get 
him a community organizer job... 
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